Re: [Distutils] Current Python packaging status (from my point of view)

2016-11-03 Thread Nathaniel Smith
On Thu, Nov 3, 2016 at 2:48 PM, Chris Barker wrote: > On Thu, Nov 3, 2016 at 3:50 AM, Paul Moore wrote: >> Or there's the >> option that's been mentioned before, but never (to my knowledge) >> developed into a complete proposal, for packaging up

Re: [Distutils] Current Python packaging status (from my point of view)

2016-11-03 Thread Chris Barker
On Thu, Nov 3, 2016 at 3:02 PM, Paul Moore wrote: > It would buy *me* flexibility to use python.org build of Python, or my > own builds. And not to have to wait for conda to release a build of a > new version. you are perfectly free to make your own conda package of python

Re: [Distutils] Current Python packaging status (from my point of view)

2016-11-03 Thread Chris Barker
On Wed, Nov 2, 2016 at 5:02 PM, Matthew Brett wrote: > Anaconda has an overwhelming advantage on Windows, in that Continuum > can bear the licensing liabilities enforced by the Intel Fortran > compiler, and we can not. Technically, that's an advantage that a commercial

Re: [Distutils] Current Python packaging status (from my point of view)

2016-11-03 Thread Paul Moore
On 3 November 2016 at 21:48, Chris Barker wrote: > On Thu, Nov 3, 2016 at 3:50 AM, Paul Moore wrote: > >> >> Even on the "hard" cases like Windows, it may be possible to define a >> standard approach that goes something along the lines of defining a >>

Re: [Distutils] Current Python packaging status (from my point of view)

2016-11-03 Thread Chris Barker
On Thu, Nov 3, 2016 at 10:56 AM, Matthew Brett wrote: > But - it would be a huge help if the PSF could help with funding to > get mingw-w64 working. This is the crucial blocker for progress on > binary wheels on Windows. for what it's worth, this is a blocker for

Re: [Distutils] Current Python packaging status (from my point of view)

2016-11-03 Thread Chris Barker
On Thu, Nov 3, 2016 at 3:50 AM, Paul Moore wrote: > Even on the "hard" cases like Windows, it may be possible to define a > standard approach that goes something along the lines of defining a > standard location that (somehow) gets added to the load path, and > interested

Re: [Distutils] Current Python packaging status (from my point of view)

2016-11-03 Thread Chris Barker
On Thu, Nov 3, 2016 at 3:39 AM, Nick Coghlan wrote: > I don't think there's much chance of any of this ever working on > Windows - conda will rule there, and rightly so. Mac OS X seems likely > to go the same way, although there's an outside chance brew may pick > up some of

Re: [Distutils] Current Python packaging status (from my point of view)

2016-11-03 Thread Chris Barker
On Thu, Nov 3, 2016 at 2:34 AM, Paul Moore wrote: > On 2 November 2016 at 23:08, Chris Barker wrote: > > After all, you can use pip from within a conda environment just fine :-) > > In my experience (some time ago) doing so ended up with the "tangled

Re: [Distutils] continuous integration options (was Re: Travis-CI is not open source, except in fact it *is* open source)

2016-11-03 Thread Alex Grönholm
I don't know if it has been mentioned before, but Travis already provides a way to automatically package and upload sdists and wheels to PyPI: https://docs.travis-ci.com/user/deployment/pypi/ I've been using it myself in many projects and it has worked quite well. Granted, I haven't had to

Re: [Distutils] continuous integration options (was Re: Travis-CI is not open source, except in fact it *is* open source)

2016-11-03 Thread Nathaniel Smith
I think we're drifting pretty far off topic here... IIRC the original discussion was about whether the travis-ci infrastructure could be suborned to provide an sdist->wheel autobuilding service for pypi. (Answer: maybe, though it would be pretty awkward, and no one seems to be jumping up to make

Re: [Distutils] continuous integration options (was Re: Travis-CI is not open source, except in fact it *is* open source)

2016-11-03 Thread Barry Warsaw
On Nov 03, 2016, at 11:08 AM, Glyph Lefkowitz wrote: >I think phrasing this in terms of "perfect" and "good enough" presents a >highly misleading framing. Examined in this fashion, of course we may >reluctantly use the "good enough" option, but don't we want the best option? What are the

[Distutils] continuous integration options (was Re: Travis-CI is not open source, except in fact it *is* open source)

2016-11-03 Thread Glyph Lefkowitz
> On Nov 3, 2016, at 10:17 AM, Barry Warsaw wrote: > > On Nov 03, 2016, at 12:54 AM, Nick Coghlan wrote: > >> This is also an area where I'm fine with recommending freemium >> solutions if they're the lowest barrier to entry option for new users, >> and "Use GitHub + Travis

Re: [Distutils] Current Python packaging status (from my point of view)

2016-11-03 Thread Matthew Brett
Hi, On Thu, Nov 3, 2016 at 2:29 AM, Paul Moore wrote: > On 3 November 2016 at 00:02, Matthew Brett wrote: >> Anaconda has an overwhelming advantage on Windows, in that Continuum >> can bear the licensing liabilities enforced by the Intel Fortran >>

Re: [Distutils] Travis-CI is not open source. Was: Current Python packaging status (from my point of view)

2016-11-03 Thread Barry Warsaw
On Nov 03, 2016, at 12:54 AM, Nick Coghlan wrote: >This is also an area where I'm fine with recommending freemium >solutions if they're the lowest barrier to entry option for new users, >and "Use GitHub + Travis CI" qualifies on that front. I won't rehash the GitHub/GitLab debate, but in some of

Re: [Distutils] Current Python packaging status (from my point of view)

2016-11-03 Thread Paul Moore
On 3 November 2016 at 10:39, Nick Coghlan wrote: > It may also be feasible to define an ABI for "linuxconda" that's > broader than the manylinux1 ABI, so folks can publish conda wheels > direct to PyPI, and then pip could define a way for distros to > indicate their ABI is

Re: [Distutils] Current Python packaging status (from my point of view)

2016-11-03 Thread Nick Coghlan
On 3 November 2016 at 19:10, Nathaniel Smith wrote: > On Nov 3, 2016 1:40 AM, "Nick Coghlan" wrote: >> The approach Tennessee and Robert Collins came up with (which still >> sounds sensible to me) is that instead of dependencies on particular >> external

Re: [Distutils] Current Python packaging status (from my point of view)

2016-11-03 Thread Paul Moore
On 2 November 2016 at 23:08, Chris Barker wrote: > After all, you can use pip from within a conda environment just fine :-) In my experience (some time ago) doing so ended up with the "tangled mess of multiple systems" you mentioned. Conda can't uninstall something I

Re: [Distutils] Current Python packaging status (from my point of view)

2016-11-03 Thread Paul Moore
On 3 November 2016 at 00:02, Matthew Brett wrote: > Anaconda has an overwhelming advantage on Windows, in that Continuum > can bear the licensing liabilities enforced by the Intel Fortran > compiler, and we can not. We therefore have no license-compatible > Fortran

Re: [Distutils] Current Python packaging status (from my point of view)

2016-11-03 Thread Nathaniel Smith
On Nov 3, 2016 1:40 AM, "Nick Coghlan" wrote: > > On 3 November 2016 at 05:28, Nathaniel Smith wrote: > > On Nov 2, 2016 9:52 AM, "Nick Coghlan" wrote: > >> Tennessee Leeuwenberg started a draft PEP for that first part last > >> year:

Re: [Distutils] Current Python packaging status (from my point of view)

2016-11-03 Thread Nick Coghlan
On 3 November 2016 at 05:28, Nathaniel Smith wrote: > On Nov 2, 2016 9:52 AM, "Nick Coghlan" wrote: >> Tennessee Leeuwenberg started a draft PEP for that first part last >> year: https://github.com/pypa/interoperability-peps/pull/30/files >> >> dnf/yum, apt,

Re: [Distutils] Current Python packaging status (from my point of view)

2016-11-03 Thread Nick Coghlan
On 3 November 2016 at 04:39, Chris Barker wrote: > On Wed, Nov 2, 2016 at 9:49 AM, Nick Coghlan wrote: >> - you need a system for specifying environmental *constraints* (like >> dynamically linked C libraries and command line applications you >> invoke)