On 11 February 2016 at 17:50, Ralf Gommers wrote:
> 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
On Thu, Feb 11, 2016 at 2:32 PM, Paul Moore wrote:
> On 11 February 2016 at 14:02, David Cournapeau wrote:
> >>> On Wed, Feb 10, 2016 at 1:52 PM, Paul Moore
> wrote:
>
> We should probably also check with the flit people
On Thu, Feb 11, 2016 at 7:43 AM, Ralf Gommers
wrote:
>
>
> 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
On 11 February 2016 at 14:02, 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
On Thu, Feb 11, 2016 at 11:16 AM, Nick Coghlan wrote:
> On 11 February 2016 at 17:50, Ralf Gommers wrote:
> > On Wed, Feb 10, 2016 at 2:43 PM, Paul Moore wrote:
> >>
> >> On 10 February 2016 at 13:23, Nick Coghlan
On 11 February 2016 at 15:01, David Cournapeau wrote:
>> We've only really seen bento and now flit appear as alternatives, the
>> only conclusion we've been able to draw is that the barrier to
>> creating alternative build systems is the need to emulate setuptools.
>> This PEP
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
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
> >>
>
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
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
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
>
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
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
On 27 January 2016 at 22:24, Paul Moore wrote:
> On 27 January 2016 at 05:39, Robert Collins wrote:
>>> - You and Paul were strongly in favor of splitting up "working directories"
>>> and "sdists"; Robert and I didn't like the idea. The argument in
On 9 February 2016 at 21:38, Robert Collins wrote:
>> In the absence of a "pip sdist" command I can see that you're saying
>> that we can implement pip's functionality without caring about this.
>> But fundamentally, people upload sdists and wheels to PyPI. A build
>>
On 10 February 2016 at 11:40, Paul Moore wrote:
> On 9 February 2016 at 21:38, Robert Collins wrote:
>>> In the absence of a "pip sdist" command I can see that you're saying
>>> that we can implement pip's functionality without caring about this.
On Tue, Feb 9, 2016 at 2:40 PM, Paul Moore wrote:
> On 9 February 2016 at 21:38, Robert Collins wrote:
>>> In the absence of a "pip sdist" command I can see that you're saying
>>> that we can implement pip's functionality without caring about this.
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.
> On 9 February 2016 at 23:19, Robert Collins wrote:
Who / what tool do we expect to use
On 27 January 2016 at 05:39, Robert Collins wrote:
>> - You and Paul were strongly in favor of splitting up "working directories"
>> and "sdists"; Robert and I didn't like the idea. The argument in favor is
>> that we have to support working directory -> sdist and sdist
On 27 January 2016 at 17:53, Robert Collins wrote:
> Yeah - note that my PR punts on this - it says PEP 427 METADATA file,
> but as we know the contents of that are a snapshot of earlier drafts
> of PEP-426, so its really not all that well defined, and before folk
> can
On 27 January 2016 at 16:37, Nathaniel Smith wrote:
> On Tue, Jan 26, 2016 at 5:08 PM, Donald Stufft wrote:
>> As many know there has been an effort to get a generalized interface that
>> a build system can implement so that we can break the hard dependency on
On 27 January 2016 at 20:30, Nathaniel Smith wrote:
>>> - Robert was in favor of a command-line based interface; I favored a hook
>>> based interface. I won't try to summarize the disagreement here b/c I'm
>>> unable to articulate any advantages of the command-line based
On Tue, Jan 26, 2016 at 9:39 PM, Robert Collins
wrote:
> On 27 January 2016 at 16:37, Nathaniel Smith wrote:
>> On Tue, Jan 26, 2016 at 5:08 PM, Donald Stufft wrote:
>>> As many know there has been an effort to get a generalized
Cool - thank you.
Right now it looks like there is one edit (add PATH as a variable folk
can depend on being set) and one undecided (metadata file format).
I've pushed a shim that permits having a setup.py for non-setuptools
projects using solely the abstract interface to
On Tue, Jan 26, 2016 at 5:08 PM, Donald Stufft wrote:
> As many know there has been an effort to get a generalized interface that
a build system can implement so that we can break the hard dependency on
setuptools that Python packaging currently has. After a lot of deliberation
25 matches
Mail list logo