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
> >> saying that in order to publish pypa.json-based source trees
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 build
>> systems apart from flit that exist
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
>> having the source in an easily consuma
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
> having the source in an easily consumable lowest common denominator format,
> the friction of
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 with
On 10.02.2016 21:26, Donald Stufft wrote:
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 th
> 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
practice, work cr
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 so. I am biased
On 11 February 2016 at 02:36, M.-A. Lemburg wrote:
>> Currently what pip does is to
>> invoke
>>
>> $ python setup.py egg_info --egg-base $TEMPDIR
>>
>> to get the metadata. It is not possible to get the metadata without
>> executing the setup.py which is problematic for many applications.
>>
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 setup.py command line API.
>>> We'd jus
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
> >>
> https://packaging.python.org/en/latest/specifications/#source-distribution-format
> >> defi
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 containing a pypa.json file
>
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
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 up the source directory, name the file "pr
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 the direction (wh
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 PyPI, would be suffic
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 interface going forwar
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 provide feedback, and
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 commands and options,
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 see implemented in
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 this a bit more, and I've re-read the
PEP. I wasn't
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
>> happen.
>
> Not
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 know the number of c
> 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" command like setuptool
24 matches
Mail list logo
