Re: [Distutils] PEP: Build system abstraction for pip/conda etc

2016-02-10 Thread Paul Moore
On 10 February 2016 at 13:43, Paul Moore wrote: >> In this case, the build system abstraction PEP should propose some >> additional text for >> https://packaging.python.org/en/latest/specifications/#source-distribution-format >> defining how to publish source archives

Re: [Distutils] Ensuring source availability for PyPI entries / PEP: Build system abstraction for pip/conda etc

2016-02-10 Thread Daniel Holth
Let me speak up about a different and pressing problem: the problem of source code that is not distributed with a GNU automake script. First, any alleged "software" that doesn't use GNU automake is not real and/or should be considered closed source. Second, automake is the best build system that I

Re: [Distutils] Ensuring source availability for PyPI entries / PEP: Build system abstraction for pip/conda etc

2016-02-10 Thread M.-A. Lemburg
On 10.02.2016 14:00, Oscar Benjamin wrote: > On 10 February 2016 at 12:21, M.-A. Lemburg wrote: >>> So "easy to achieve" still needs someone to take the time to deal with >>> these sorts of issue. It's the usual process of the people willing to >>> put in the effort get to choose

Re: [Distutils] PEP: Build system abstraction for pip/conda etc

2016-02-10 Thread David Cournapeau
On Wed, Feb 10, 2016 at 1:52 PM, Paul Moore wrote: > On 10 February 2016 at 13:43, Paul Moore wrote: > >> In this case, the build system abstraction PEP should propose some > >> additional text for > >> >

Re: [Distutils] PEP: Build system abstraction for pip/conda etc

2016-02-10 Thread Paul Moore
On 10 February 2016 at 13:23, Nick Coghlan wrote: > On 10 February 2016 at 20:53, Paul Moore wrote: >> We don't have to solve the whole "sdist 2.0" issue right now. Simply >> saying that in order to publish pypa.json-based source trees you need >> to zip

Re: [Distutils] Ensuring source availability for PyPI entries / PEP: Build system abstraction for pip/conda etc

2016-02-10 Thread Robert Collins
On 11 February 2016 at 01:21, M.-A. Lemburg wrote: > On 10.02.2016 12:10, Paul Moore wrote: >> On 10 February 2016 at 10:23, M.-A. Lemburg wrote: >>> IMO, that's easy to achieve, though, with the existing de-facto >>> standard interface we already have: the

Re: [Distutils] [final version?] PEP 513 - A Platform Tag for Portable Linux Built Distributions

2016-02-10 Thread Donald Stufft
> On Feb 10, 2016, at 3:18 PM, Matthias Klose wrote: > > But then why call it manylinux instead of centos5? You build it on this OS, > you expect others to build it on this OS. just name it what it is. Because this is a very specific subset of CentOS 5 that has shown to, in

Re: [Distutils] [final version?] PEP 513 - A Platform Tag for Portable Linux Built Distributions

2016-02-10 Thread Matthias Klose
On 02.02.2016 01:30, Donald Stufft wrote: On Feb 1, 2016, at 6:37 PM, Matthias Klose wrote: On 30.01.2016 00:29, Nathaniel Smith wrote: Hi all, I think this is ready for pronouncement now -- thanks to everyone for all their feedback over the last few weeks! I don't think

Re: [Distutils] Ensuring source availability for PyPI entries / PEP: Build system abstraction for pip/conda etc

2016-02-10 Thread Barry Warsaw
On Feb 10, 2016, at 10:08 AM, Paul Moore wrote: >But those people will then find that distributing their sources isn't >something that flit covers, so they'll make up their own approach (if it were >me, I'd probably just point people at the project's github account). > >Once people get set up

Re: [Distutils] Ensuring source availability for PyPI entries / PEP: Build system abstraction for pip/conda etc

2016-02-10 Thread Nick Coghlan
On 11 February 2016 at 13:48, Nick Coghlan wrote: > On 11 February 2016 at 08:12, Barry Warsaw wrote: >> It's not impossible to migrate to something else, but it's impractical to >> migrate to dozens of something elses. Right now, if we can count on PyPI >>

Re: [Distutils] PEP: Build system abstraction for pip/conda etc

2016-02-10 Thread Ralf Gommers
On Wed, Feb 10, 2016 at 3:30 PM, David Cournapeau wrote: > > > > On Wed, Feb 10, 2016 at 1:52 PM, Paul Moore wrote: > >> We should probably also check with the flit people that the proposed >> approach works for them. (Are there any other alternative

Re: [Distutils] PEP: Build system abstraction for pip/conda etc

2016-02-10 Thread Ralf Gommers
On Wed, Feb 10, 2016 at 2:43 PM, Paul Moore wrote: > On 10 February 2016 at 13:23, Nick Coghlan wrote: > > On 10 February 2016 at 20:53, Paul Moore wrote: > >> We don't have to solve the whole "sdist 2.0" issue right now. Simply >

Re: [Distutils] Ensuring source availability for PyPI entries / PEP: Build system abstraction for pip/conda etc

2016-02-10 Thread M.-A. Lemburg
> Paul Moore writes: > >> But as I said in my response to Nathaniel, it may be that all that is >> needed is some context in the PEP explaining how we require[1] people >> to upload source to PyPI in the new world where we support build >> systems which don't have a "sdist"

Re: [Distutils] Ensuring source availability for PyPI entries / PEP: Build system abstraction for pip/conda etc

2016-02-10 Thread Paul Moore
On 10 February 2016 at 10:23, M.-A. Lemburg wrote: > IMO, that's easy to achieve, though, with the existing de-facto > standard interface we already have: the setup.py command line API. > We'd just need to publish the minimal set of commands and options, > installer will want to

Re: [Distutils] Ensuring source availability for PyPI entries / PEP: Build system abstraction for pip/conda etc

2016-02-10 Thread Paul Moore
On 10 February 2016 at 09:34, M.-A. Lemburg wrote: > I'm not sure I'm parsing your comment correctly, but if you are > suggesting that PyPI should no longer allow supporting > non-open-source packages, this is definitely not going to > happen. Not at all. Although as far as I

Re: [Distutils] Ensuring source availability for PyPI entries / PEP: Build system abstraction for pip/conda etc

2016-02-10 Thread M.-A. Lemburg
On 10.02.2016 11:08, Paul Moore wrote: > On 10 February 2016 at 09:34, M.-A. Lemburg wrote: >> I'm not sure I'm parsing your comment correctly, but if you are >> suggesting that PyPI should no longer allow supporting >> non-open-source packages, this is definitely not going to >>

Re: [Distutils] PEP: Build system abstraction for pip/conda etc

2016-02-10 Thread Paul Moore
On 10 February 2016 at 01:19, Robert Collins wrote: > On 10 February 2016 at 13:09, Paul Moore wrote: >> [I need to read and digest the rest of this, but it's late here, so >> that will be tomorrow] > > OK, cool. Right, I've been thinking about

Re: [Distutils] Ensuring source availability for PyPI entries / PEP: Build system abstraction for pip/conda etc

2016-02-10 Thread M.-A. Lemburg
On 10.02.2016 12:10, Paul Moore wrote: > On 10 February 2016 at 10:23, M.-A. Lemburg wrote: >> IMO, that's easy to achieve, though, with the existing de-facto >> standard interface we already have: the setup.py command line API. >> We'd just need to publish the minimal set of

Re: [Distutils] Ensuring source availability for PyPI entries / PEP: Build system abstraction for pip/conda etc

2016-02-10 Thread Oscar Benjamin
On 10 February 2016 at 12:21, M.-A. Lemburg wrote: >> So "easy to achieve" still needs someone to take the time to deal with >> these sorts of issue. It's the usual process of the people willing to >> put in the effort get to choose the direction (which is also why I >> just

Re: [Distutils] Ensuring source availability for PyPI entries / PEP: Build system abstraction for pip/conda etc

2016-02-10 Thread Nick Coghlan
On 10 February 2016 at 22:21, M.-A. Lemburg wrote: > Wait. You are missing the point that the setup.py interface > already does work, so no extra effort is needed. All that's > needed is some documentation of what's currently being used, > so that other tools can support the

Re: [Distutils] PEP: Build system abstraction for pip/conda etc

2016-02-10 Thread Nick Coghlan
On 10 February 2016 at 20:53, Paul Moore wrote: > We don't have to solve the whole "sdist 2.0" issue right now. Simply > saying that in order to publish pypa.json-based source trees you need > to zip up the source directory, name the file "project-version.zip" > and upload to