On Fri, Apr 7, 2017 at 4:58 PM, Chris Barker <chris.bar...@noaa.gov> wrote:
> On Thu, Apr 6, 2017 at 5:34 PM, Wes Turner <wes.tur...@gmail.com> wrote: > > >> 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. >>> >> >> Someone still needs to commit to maintaining the conda package; otherwise >> who knows whether this is the latest stable release? >> > > 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. > So then there's pulling from a specific source rev: pip install -e git+ssh://g...@github.com/pypa/pip@9.0.1#egg=pip There was a discussion about adding the git/hg/svn/vcs source URI to each package's metadata: - "add "sourceURL" to the metadata 3.0 PEP." https://www.mail-archive.com/distutils-sig@python.org/msg25836.html https://www.mail-archive.com/distutils-sig@python.org/msg25833.html - Project-URL - Source-URL (metadata 2.0) AFAIU, the only way to read the package version from the {git, hg, } source repository is to run the setup.py. There's a semver way to specify the vcs revision ("git short SHA") in the package identifier: https://github.com/openstack-dev/pbr/pull/14/commits/5b7a619046eb10ed3fa7bb987be95208faf2fda3 > > >>> 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. >>> >> >> Docker images are reproducible and archivable: >> > > 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. > IIUC, this should work w/ Docker for {Linux, Windows, OSX, }: docker run -i -t continuumio/miniconda3 /bin/bash AFAIU, If you instead wanted to run Windows containers on a Windows host, you'd need Windows Server 2016: https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/quick-start-windows-server You can run "provisioner(s)" (shell script, salt states, ansible playbooks) at image build time with e.g. Packer: https://www.packer.io/docs/basics/terminology.html 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"). > > Not that Docker isn't a really useful tool to htlep address some of these > problems... > > -CHB > > > >> What platforms does conda-forge auto-build for? >> - [x] x86[-64] >> > > linux-64 > win-32 > win-64 > osx-64 > > (all Intel) > > > > - [ ] linux-armv7l >> - https://github.com/conda-forge/conda-forge.github.io/issues/269 >> > > > 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 > > It's an open-source project -- if it's important to someone, it will get > done. > Raspberry Pi support for conda-forge would probably be really useful for education. IDK what sort of resources would be needed to add Pi2's to the CI build farm?
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
