You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I searched open requests and couldn't find a duplicate
What is the idea?
constructor is able to generate installers for Linux, macOS, and Windows, using an array of formats (SH, PKG, EXE, respectively). However, there's nothing special about these "installers" they are just "artifacts" that "pack" a number of conda packages.
The idea here would be to teach constructor how to generate additional artifact formats, like:
Docker containers via conda-docker
Tarballs via conda-pack
Why is this needed?
constructor would slowly become an interface for packaging and distributing conda environments. There is plenty of duplicated logic across this projects and we would benefit from a single maintenance hub for all of them. There are bits of conda-pack internals that would be lovely to have in constructor's code (like the Environment abstraction).
We could take a look and see how feasible this is. constructor was always built with the "installer" idea in mind, so some concepts in the config file and code base might be too coupled. In that case, a separate tool that encompasses all these usages with their nuances could be better welcome (e.g. conda-bundle).
The text was updated successfully, but these errors were encountered:
Checklist
What is the idea?
constructor
is able to generate installers for Linux, macOS, and Windows, using an array of formats (SH, PKG, EXE, respectively). However, there's nothing special about these "installers" they are just "artifacts" that "pack" a number of conda packages.The idea here would be to teach constructor how to generate additional artifact formats, like:
conda-docker
conda-pack
Why is this needed?
constructor
would slowly become an interface for packaging and distributing conda environments. There is plenty of duplicated logic across this projects and we would benefit from a single maintenance hub for all of them. There are bits ofconda-pack
internals that would be lovely to have inconstructor
's code (like the Environment abstraction).What should happen?
Users could just have a
construct.yml
like this:Additional Context
This is the other side of conda/conda-pack#294.
We could take a look and see how feasible this is.
constructor
was always built with the "installer" idea in mind, so some concepts in the config file and code base might be too coupled. In that case, a separate tool that encompasses all these usages with their nuances could be better welcome (e.g.conda-bundle
).The text was updated successfully, but these errors were encountered: