-
-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exporting an environment #45
Comments
I agree that something like this would be useful. Some random thoughts:
|
Thats very useful, thanks @mrocklin. Closing for now. |
Lets keep it open for now if that's alright. This is a valuable goal to keep in mind. |
@jcrist 's conda-pack might also be of interest. Ideally for the workers we can even drop conda and just distribute a zip of an environment. |
+1 - especially for an approach like the conda-pack method, which feels a bit lighter weight, if possibly less generic. |
The classic |
Is it worth adding a couple of util scripts that would export the users current environment (conda or virtual env) and builds a docker image on top of
daskdev/dask:latest
?Being able to pass a list of conda/pip packages is fine for relatively simple environments / prototyping but I can see value in something slightly more stable. Building a new image (Shouldn't need to be done too often) will increase the connection time to the KubeCluster, but will reduce the worker start up time.
I have some basic POC of this, which I am currently using, which looks something like
daskdev/dask:latest
, using something likeIs this in the works? Or any thoughts on the above?
The text was updated successfully, but these errors were encountered: