Difference to constructor

[certik]

What's the difference between conda-pack and constructor? When would you use one and when the other? What are the pros and cons of each?

[jcrist]

• conda-pack is for packaging an existing environment in a way that it's relocatable. The output is an archive file that needs to be unpacked, as well as a single script in that file that sometimes needs to be run beforehand to fixup absolute paths in files in the environment (usually not necessary for Python libraries, may be needed if you have other binary artifacts). I originally created this to deploy Python applications on clusters (e.g. YARN) in a consistent environment, but it may have other uses.

• constructor is for creating an installer for a new environment from a specification. This installer is similar to the one miniconda uses to install itself - once run everything is installed properly on the deployment machine. Constructor can be used to create install scripts on machines that don't have the same OS as the machine constructor was run on, something that conda-pack cannot do. Constructor does not currently support noarch: python packages, or non-conda packages (both of which conda-pack can do).

---

In short, the major differences (minus bugs and current limitations, which are fixable) are:

• conda-pack packages an existing environment, with whatever conda/other packages are installed. constructor packages a new environment from a spec of conda packages.

• conda-pack outputs an archive to be unarchived on the deployment machine, constructor outputs an install script to be run on the deployment machine.

[certik]

I was told that constructor is not maintained. So that leaves conda-pack as the only viable option to create an installer.

[mingwandroid]

It is maintained.

[certik]

@mingwandroid oh, my apologies then. I'll give it a shot also.

[scopatz]

Hmm my understanding was that it wasn't good for us to use conda-constructor

[mingwandroid]

In what regards? We use it extensively, Miniconda and Anaconda installers are all built on it and I don't see that changing anytime soon.

Now would I recommend constructor over competing technologies? From a clean slate, no way (it has 3 basically independent back ends for a start) but since it exists and works it serves a useful purpose.

[scopatz]

My understanding is that constructor does not work for noarch packages, and at least for conda-forge we were asked not to use constructor. This is totally fine, but my general impression is that conda-constructor is sort of an Anaconda internal tool.

[jcrist]

@scopatz , was that the correct link? That post is about not using constructor to create a conda-forge-only miniconda-like distro, not about not using constructor at all.

Yes, constructor doesn't currently work for noarch packages. It also has a different intended use case than conda-pack. To reiterate what I said above #45 (comment), this project was intended mainly for distributing Python environments in deployment scenarios (mainly for clusters, YARN specifically, but there are other use cases) - constructor is for creating installers, which may be more user facing.

[scopatz]

Right, so the two big blockers for use for conda-constructor are the noarch issue and being asked not to use it for conda-forge (which again, I am fine with and don't want to relitigate here 😄).

[certik]

@scopatz, @jcrist, @mingwandroid I am just really confused. I am looking for a tool that allows me to create 3 tarballs (one for each Linux, Mac, and Windows), that I can move over to a computer without an internet connection that will unpack, and allow me to run our production application. It doesn't need to install Conda, but it needs to be easy enough to use for users of the application.

What would you recommend I use?

[msarahan]

That seems like a good use for conda-pack, more than constructor.

[jcrist]

That seems like a good use for conda-pack, more than constructor.

Agreed, depending on sophistication of the users. If constructor supported all the packages you needed (e.g. no noarch packages) I might recommend that over conda-pack, as it's only a single step (run the installer) rather than unpack to a directory, activate the environment, and (optionally) run the conda-unpack script. But yes, this is a valid usecase for conda-pack.

[github-actions]

Hi there, thank you for your contribution!

This issue has been automatically locked because it has not had recent activity after being closed.

Please open a new issue if needed.

Thanks!