<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 7, 2017 at 4:58 PM, Chris Barker <span dir="ltr"><<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On Thu, Apr 6, 2017 at 5:34 PM, Wes Turner <span dir="ltr"><<a href="mailto:wes.turner@gmail.com" target="_blank">wes.turner@gmail.com</a>></span> wrote:<br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_-543405948456136536gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Chances are, there will be a package or two that you rely on that is not in conda defaults (maintained by Continuum) or currently in conda-forge. So you can pip-install those few -- but what if they aren't on PyPi either? or are hard to compile and install with ugly dependencies? You can contribute build recipes to conda-forge, and then have it for you, and all your users, and the rest of the world to access. Much better than hand maintaining stuff yourself.</div></div></div></div></blockquote><div><br></div></span><div>Someone still needs to commit to maintaining the conda package; otherwise who knows whether this is the latest stable release?</div></blockquote><div><br></div></span><div>Indeed. and it it's a not-that-widely-used package, then you will have to do that yourself -- but using the conda-forge infrastructure makes that (relatively) easy. In contrast -- who knows whether the package on PyPi is the latest stable release? Hopefully the maintainer is keeping it up, but if not, you're kinda dead in the water.</div></div></div></div></blockquote><div><br></div><div>So then there's pulling from a specific source rev:</div><div><br></div><div> pip install -e git+ssh://<a href="http://git@github.com/pypa/pip@9.0.1#egg=pip">git@github.com/pypa/pip@9.0.1#egg=pip</a></div><div><br></div><div><br></div><div>There was a discussion about adding the git/hg/svn/vcs source URI to each package's metadata:</div><div>- "add "sourceURL" to the metadata 3.0 PEP."</div><div> <a href="https://www.mail-archive.com/distutils-sig@python.org/msg25836.html">https://www.mail-archive.com/distutils-sig@python.org/msg25836.html</a><br></div><div> <a href="https://www.mail-archive.com/distutils-sig@python.org/msg25833.html">https://www.mail-archive.com/distutils-sig@python.org/msg25833.html</a></div><div> - Project-URL</div><div> - Source-URL (metadata 2.0)</div><div><br></div><div>AFAIU, the only way to read the package version from the {git, hg, } source repository is to run the setup.py.</div><div><br></div><div>There's a semver way to specify the vcs revision ("git short SHA") in the package identifier:</div><div><a href="https://github.com/openstack-dev/pbr/pull/14/commits/5b7a619046eb10ed3fa7bb987be95208faf2fda3">https://github.com/openstack-dev/pbr/pull/14/commits/5b7a619046eb10ed3fa7bb987be95208faf2fda3</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_-543405948456136536gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>My pain point now is still full multi-platform support. conda has package versions that are platform independent, but it can still be hard to get everything built in the same version on all platforms, so it does get a bit ugly.</div></div></div></div></blockquote><div><br></div></span><div>Docker images are reproducible and archivable:</div></blockquote><div><br></div></span><div>In a way Docker, as I understand it, is orthogonal to this conversation. And when I talk about "all platforms", I mean running natively on all platforms -- I can't give my Windows users a Linux VM and expect them to know what the heck to do with it.</div></div></div></div></blockquote><div><br></div><div>IIUC, this should work w/ Docker for {Linux, Windows, OSX, }:</div><div><br></div><div> docker run -i -t continuumio/miniconda3 /bin/bash</div><div><br></div><div>AFAIU, If you instead wanted to run Windows containers on a Windows host, you'd need Windows Server 2016:</div><div><a href="https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/quick-start-windows-server">https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/quick-start-windows-server</a><br></div><div><br></div><div>You can run "provisioner(s)" (shell script, salt states, ansible playbooks) at image build time with e.g. Packer:</div><div><a href="https://www.packer.io/docs/basics/terminology.html">https://www.packer.io/docs/basics/terminology.html</a></div><div><br></div><div>With a configuration management tool like salt or ansible, you can define configuration policies with conditionals for whichever given platform specs (and see it all in one place as "infrastructure as code").</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Not that Docker isn't a really useful tool to htlep address some of these problems...</div><div><br></div><div>-CHB</div><span class="gmail-"><div> <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>What platforms does conda-forge auto-build for?<br></div><div>- [x] x86[-64]</div></blockquote></span><div><br> linux-64 <br> win-32 <br> win-64 <br> osx-64 <br></div><div><br></div><div>(all Intel)</div><span class="gmail-"><div><br></div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>- [ ] linux-armv7l</div><div> - <a href="https://github.com/conda-forge/conda-forge.github.io/issues/269" target="_blank">https://github.com/conda-for<wbr>ge/conda-forge.github.io/issue<wbr>s/269</a></div>
</blockquote></span></div><br><br>looks like folks are trying, but it's not really there yet -- mostly due to the lack of easy to access CI services for armv7I</div><div class="gmail_extra"><br></div><div class="gmail_extra">It's an open-source project -- if it's important to someone, it will get done.</div></div></blockquote><div><br></div><div>Raspberry Pi support for conda-forge would probably be really useful for education.</div><div>IDK what sort of resources would be needed to add Pi2's to the CI build farm?</div><div> </div></div></div></div>