On 4 May 2016 at 16:03, Robert Collins wrote:
> The edits I'd expect to make if the conclusions I suggested in
> https://mail.python.org/pipermail/distutils-sig/2016-March/028437.html
> are adopted are:
>
> - change to a Python API
> - BFDL call on the file format and name
>
> There is no need t
> On May 4, 2016, at 3:39 AM, Nick Coghlan wrote:
>
> On 4 May 2016 at 16:03, Robert Collins wrote:
>> The edits I'd expect to make if the conclusions I suggested in
>> https://mail.python.org/pipermail/distutils-sig/2016-March/028437.html
>> are adopted are:
>>
>> - change to a Python API
>>
+1 It would be great to start with a real setup_requires and probably would
not interfere with later build system abstractions at all.
On Wed, May 4, 2016 at 6:33 AM Donald Stufft wrote:
>
> > On May 4, 2016, at 3:39 AM, Nick Coghlan wrote:
> >
> > On 4 May 2016 at 16:03, Robert Collins
> wrot
On 4 May 2016 at 23:00, Daniel Holth wrote:
> +1 It would be great to start with a real setup_requires and probably would
> not interfere with later build system abstractions at all.
If we're going to go down that path, perhaps it might make sense to
just define a standard [setup_requires] sectio
Agree.
On Wed, May 4, 2016, 09:28 Nick Coghlan wrote:
> On 4 May 2016 at 23:00, Daniel Holth wrote:
> > +1 It would be great to start with a real setup_requires and probably
> would
> > not interfere with later build system abstractions at all.
>
> If we're going to go down that path, perhaps i
On Wed, May 4, 2016 at 4:02 PM, Paul R. Tagliamonte
wrote:
> Hey all,
>
> For those who don't know, Trove classifiers are used by the Python
> world to talk about what is contained in the Python package. Stuff
> like saying "It's under the MIT/Expat license!" or "It's beta!".
>
>
> I was looking a
On 4 May 2016 at 19:39, Nick Coghlan wrote:
> On 4 May 2016 at 16:03, Robert Collins wrote:
>> The edits I'd expect to make if the conclusions I suggested in
>> https://mail.python.org/pipermail/distutils-sig/2016-March/028437.html
>> are adopted are:
>>
>> - change to a Python API
>> - BFDL ca
Just call it Steve
On Wed, May 4, 2016, 16:25 Robert Collins wrote:
> On 4 May 2016 at 19:39, Nick Coghlan wrote:
> > On 4 May 2016 at 16:03, Robert Collins
> wrote:
> >> The edits I'd expect to make if the conclusions I suggested in
> >> https://mail.python.org/pipermail/distutils-sig/2016-Ma
On 4 May 2016 at 22:33, Donald Stufft wrote:
>
..> I also believe that we can't provide a replacement for setup.py
without either
> purposely declaring we no longer support something that people used from it or
> providing a way to support that in the new, setup.py-less format.
The thunk I wrote
On Wed, May 4, 2016 at 3:33 AM, Donald Stufft wrote:
> I'd actually prefer not using JSON for something that is human
> editable/writable because I think it's a pretty poor format for that case.
> It
> is overly restrictive in what it allows (for instance, no trailing comma
> gets
> me every time
On 4 May 2016 at 23:11, Chris Barker wrote:
> so it could be purely declarative, but users could also put code in there to
> customize the configuration on the fly, too.
That basically repeats the mistake that was made with setup.py. We
explicitly don't want an executable format for specifying bu
On 05/04/2016 03:28 PM, Paul Moore wrote:
On 4 May 2016 at 23:11, Chris Barker wrote:
That basically repeats the mistake that was made with setup.py. We
explicitly don't want an executable format for specifying build
configuration.
Executable code or not, we need to be able to specify diffe
Different files for what? Something not covered by PEP 508?
05.05.2016, 02:23, Ethan Furman kirjoitti:
On 05/04/2016 03:28 PM, Paul Moore wrote:
On 4 May 2016 at 23:11, Chris Barker wrote:
That basically repeats the mistake that was made with setup.py. We
explicitly don't want an executable
On 05/04/2016 04:29 PM, Alex Grönholm wrote:
Different files for what? Something not covered by PEP 508?
Somebody will have to distill that PEP, I have only an small inkling of
what it's trying to say.
As for my specific use case: I have Python3-only files in my
distribution, so they shou
The only part that needs to be static is the metadata. The actual build can
have code without hindering our dependency resolution aspirations.
On Wed, May 4, 2016, 19:59 Ethan Furman wrote:
> On 05/04/2016 04:29 PM, Alex Grönholm wrote:
>
> > Different files for what? Something not covered by PE
Hi all,
I've fallen seriously behind in trying to admin PyPI by myself, and I'm
calling for someone to help. Generally this means helping people reset
their email address for account recovery, or trying to contact owners of
packages to facilitate ownership changes. The *ahem* "tools" available
are
On 5 May 2016 at 08:28, Paul Moore wrote:
> On 4 May 2016 at 23:11, Chris Barker wrote:
>> so it could be purely declarative, but users could also put code in there to
>> customize the configuration on the fly, too.
>
> That basically repeats the mistake that was made with setup.py. We
> explicit
On 5 May 2016 at 06:28, Robert Collins wrote:
> the only reason I got involved in build system discussions was
> pushback 18months or so back when I implemented a proof of concept for
> pip that just used setup.cfg. I'd be very happy to ignore all the
> build system stuff and just do bootstrap req
Ok so, if i draft a pep for said proposal, will it die under the weight of
a thousand bike sheds?
On 5 May 2016 3:09 PM, "Nick Coghlan" wrote:
> On 5 May 2016 at 06:28, Robert Collins wrote:
> > the only reason I got involved in build system discussions was
> > pushback 18months or so back when
On Wed, May 4, 2016 at 6:28 AM, Nick Coghlan wrote:
> On 4 May 2016 at 23:00, Daniel Holth wrote:
>> +1 It would be great to start with a real setup_requires and probably would
>> not interfere with later build system abstractions at all.
>
> If we're going to go down that path, perhaps it might
Hey all,
Just a heads up that due to hitting query timeouts when attempting to lookup
serials I changed the way serials work and are queried on PyPI. This should
have no visible changes to end users but keep an eye out for serials that don't
look correct, particularly via bandersnatch failures
On 5 May 2016 at 16:22, Nathaniel Smith wrote:
...
> I'm sympathetic to the general approach, but on net I think I prefer a
> slightly different proposal.
>
> Downsides to just standardizing [setup_requires]:
If I write a PEP, it won't be standardising setup_requires, it will be
standardising boo
On Wed, May 4, 2016 at 10:42 PM, Robert Collins
wrote:
> On 5 May 2016 at 16:22, Nathaniel Smith wrote:
> ...
>> I'm sympathetic to the general approach, but on net I think I prefer a
>> slightly different proposal.
>>
>> Downsides to just standardizing [setup_requires]:
>
> If I write a PEP, it
On 5 May 2016 at 18:32, Nathaniel Smith wrote:
> On Wed, May 4, 2016 at 10:42 PM, Robert Collins
>...
>> Yes, things will break: anyone using this will need a new pip, by
>> definition. Not everyone will be willing to wait 10 years before using
>> it :).
>
> Just to clarify (since we seem to agree
24 matches
Mail list logo
