[Distutils] Which commercial vendor?

Wes Turner wes.turner at gmail.com
Fri Apr 7 19:51:08 EDT 2017

On Fri, Apr 7, 2017 at 4:58 PM, Chris Barker <chris.barker at noaa.gov> wrote:

> On Thu, Apr 6, 2017 at 5:34 PM, Wes Turner <wes.turner at 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://git@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."
  - 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:

>>> 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:

You can run "provisioner(s)" (shell script, salt states, ansible playbooks)
at image build time with e.g. Packer:

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
IDK what sort of resources would be needed to add Pi2's to the CI build
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170407/348c6556/attachment-0001.html>

More information about the Distutils-SIG mailing list