Redeployable conda environments
<p>I want to create a conda environment on my laptop that I can deploy to my cluster.  For this I want two things:</p>

<ol>
<li>To be able to create a conda environment for a different architecture</li>
<li>To be able to zip up the environment, move it to some other place in some other file system, unzip it, and run <code>/path/to/myenv/bin/python ...</code></li>
</ol>

<p>I hope that there is some option in conda-create to specify an architecture like the following:</p>

<pre><code>conda create --arch=linux-64 ...
</code></pre>

<p>For redeployability I have tried using the <code>--copy</code> option to avoid hard-links and this <em>seems</em> to work fine, at least in simple cases.  Are there cases or common packages where this approach will fail?  Are there other things I can do either to increase effectiveness or warn when a package depends on files outside of the environment?</p>

<p>At present, conda does not have a direct way to create environments for arbitrary architectures.  I'm also not sure exactly how feasible it is.  For the vast majority of packages, it's just a metadata thing, and is totally workable.  For binary packages, though, we (sometimes) have to replace the prefix that is embedded in the binary.  Since it is done in Python (<a href="https://github.com/conda/conda/blob/9c1750349b4c1d66a9caf95d21a9edf90e1eb9cf/conda/install.py#L250-L271" rel="nofollow">https://github.com/conda/conda/blob/9c1750349b4c1d66a9caf95d21a9edf90e1eb9cf/conda/install.py#L250-L271</a>), I think it will work - but if there's any chance of binaries not being understood (Mac creating a Linux env, for example), this may break.</p>

<p>We can certainly hack up a PoC and see how it works.</p>

<p>Packages really shouldn't depend on outside files, aside from perhaps some really core system libraries (glibc, for example).  Warning people at build time would be a good thing, but I don't think it is an install-time concern.</p>

python conda