Re: [Distutils] Finishing up PEP 517

[Daniel Holth]

The other thing I noticed is that build-system requires has no hyphen but
build-backend does.

On Wed, Jun 28, 2017, 22:28 Daniel Holth  wrote:

> That would fit with setup.py, which also likes to sys.exit() after one
> command.
>
> On Wed, Jun 28, 2017, 22:25 Nick Coghlan  wrote:
>
>> On 29 June 2017 at 11:42, Daniel Holth  wrote:
>> > I was able to implement PEP 517 build_wheel and build_sdist for enscons
>> (on
>> > bitbucket), and a click cli calling any backend mentioned in
>> pyproject.toml.
>> > Pretty simple. Not sure what to do with the config dictionary.
>>
>> That's designed to allow frontends to tunnel custom settings from the
>> user through to the backend, so if you don't support any config
>> settings yet, it probably makes sense to just error out with "Unknown
>> config setting" if the dictionary is non-empty. Alternatively, you
>> could silently ignore it.
>>
>> > SCons is not designed to be called twice in the same process with
>> different
>> > arguments. It would be easier for me to know that pip would only invoke
>> one
>> > PEP 517 function per subprocess, or to know all target directories in
>> > advance. Otherwise the enscons.api subprocess has to invoke SCons in
>> another
>> > subprocess. SCons also builds all targets (wheel and sdist in same
>> > invocation) by default.
>>
>> That's an interesting point of tension between supporting imperative
>> frontends like pip (which have a strong opinion about the order in
>> which steps should be executed) and declarative build systems like
>> Scons (which are more "produce the defined artifact set").
>>
>> However, I think the way to go for now would be to say:
>>
>> - each hook call should be made in a fresh subprocess (so backends
>> don't need to use a second subprocess "just to be on the safe side")
>> - in a *future* API extension, we may add an optional "build_all" hook
>> (whereby the backend produced both an sdist and all wheels it knew how
>> to create for the current platform), but anything like that will be
>> out of scope for the initial PEP 517 API
>>
>> Cheers,
>> Nick.
>>
>> --
>> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Finishing up PEP 517

[Daniel Holth]

That would fit with setup.py, which also likes to sys.exit() after one
command.

On Wed, Jun 28, 2017, 22:25 Nick Coghlan  wrote:

> On 29 June 2017 at 11:42, Daniel Holth  wrote:
> > I was able to implement PEP 517 build_wheel and build_sdist for enscons
> (on
> > bitbucket), and a click cli calling any backend mentioned in
> pyproject.toml.
> > Pretty simple. Not sure what to do with the config dictionary.
>
> That's designed to allow frontends to tunnel custom settings from the
> user through to the backend, so if you don't support any config
> settings yet, it probably makes sense to just error out with "Unknown
> config setting" if the dictionary is non-empty. Alternatively, you
> could silently ignore it.
>
> > SCons is not designed to be called twice in the same process with
> different
> > arguments. It would be easier for me to know that pip would only invoke
> one
> > PEP 517 function per subprocess, or to know all target directories in
> > advance. Otherwise the enscons.api subprocess has to invoke SCons in
> another
> > subprocess. SCons also builds all targets (wheel and sdist in same
> > invocation) by default.
>
> That's an interesting point of tension between supporting imperative
> frontends like pip (which have a strong opinion about the order in
> which steps should be executed) and declarative build systems like
> Scons (which are more "produce the defined artifact set").
>
> However, I think the way to go for now would be to say:
>
> - each hook call should be made in a fresh subprocess (so backends
> don't need to use a second subprocess "just to be on the safe side")
> - in a *future* API extension, we may add an optional "build_all" hook
> (whereby the backend produced both an sdist and all wheels it knew how
> to create for the current platform), but anything like that will be
> out of scope for the initial PEP 517 API
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Finishing up PEP 517

[Nick Coghlan]

On 29 June 2017 at 11:42, Daniel Holth  wrote:
> I was able to implement PEP 517 build_wheel and build_sdist for enscons (on
> bitbucket), and a click cli calling any backend mentioned in pyproject.toml.
> Pretty simple. Not sure what to do with the config dictionary.

That's designed to allow frontends to tunnel custom settings from the
user through to the backend, so if you don't support any config
settings yet, it probably makes sense to just error out with "Unknown
config setting" if the dictionary is non-empty. Alternatively, you
could silently ignore it.

> SCons is not designed to be called twice in the same process with different
> arguments. It would be easier for me to know that pip would only invoke one
> PEP 517 function per subprocess, or to know all target directories in
> advance. Otherwise the enscons.api subprocess has to invoke SCons in another
> subprocess. SCons also builds all targets (wheel and sdist in same
> invocation) by default.

That's an interesting point of tension between supporting imperative
frontends like pip (which have a strong opinion about the order in
which steps should be executed) and declarative build systems like
Scons (which are more "produce the defined artifact set").

However, I think the way to go for now would be to say:

- each hook call should be made in a fresh subprocess (so backends
don't need to use a second subprocess "just to be on the safe side")
- in a *future* API extension, we may add an optional "build_all" hook
(whereby the backend produced both an sdist and all wheels it knew how
to create for the current platform), but anything like that will be
out of scope for the initial PEP 517 API

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Finishing up PEP 517

[Daniel Holth]

I was able to implement PEP 517 build_wheel and build_sdist for enscons (on
bitbucket), and a click cli calling any backend mentioned in
pyproject.toml. Pretty simple. Not sure what to do with the config
dictionary.

SCons is not designed to be called twice in the same process with different
arguments. It would be easier for me to know that pip would only invoke one
PEP 517 function per subprocess, or to know all target directories in
advance. Otherwise the enscons.api subprocess has to invoke SCons in
another subprocess. SCons also builds all targets (wheel and sdist in same
invocation) by default.

"Alakazam!"

On Wed, Jun 28, 2017 at 3:52 PM Thomas Kluyver  wrote:

> On Wed, Jun 28, 2017, at 06:07 PM, Daniel Holth wrote:
>
> Is there a prototype implementation of pep 517 yet?
>
>
> - Flit has a PR with a prototype backend implementation, though it's not
> up to date with all the changes the PEP has undergone. I'll update it when
> we've agreed on a spec - it's still a fast moving target right now.
> - I have a prototype module frontends could use to call hooks here:
> https://github.com/takluyver/pep517 . It's mostly up to date, except for
> the issue with using sdist as a fallback for copying files for a wheel.
>
> Re: magic strings - like Nathaniel said, I haven't noticed them as part of
> any proposal so far.
>
> Thomas
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Finishing up PEP 517

[Thomas Kluyver]

On Wed, Jun 28, 2017, at 06:07 PM, Daniel Holth wrote:
> Is there a prototype implementation of pep 517 yet?



- Flit has a PR with a prototype backend implementation, though it's
  not up to date with all the changes the PEP has undergone. I'll
  update it when we've agreed on a spec - it's still a fast moving
  target right now.- I have a prototype module frontends could use to call 
hooks here:
  https://github.com/takluyver/pep517 . It's mostly up to date,
  except for the issue with using sdist as a fallback for copying
  files for a wheel.
Re: magic strings - like Nathaniel said, I haven't noticed them as part of any 
proposal so far.
Thomas
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Finishing up PEP 517

[Nathaniel Smith]

I don't think anyone has proposed anything involving magic strings?

On Jun 28, 2017 3:58 AM, "Robert Collins"  wrote:

>
>
> Re: returning magic strings to indicate exceptions. Please no. Just no.
> Have any pep build host add a small library to Python path with any symbols
> we want to define. Hardly an implementation hurdle.
>
> Rob
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Provide separate development and documentation URLs in PyPI metadata?

[Brett Cannon]

On Tue, 27 Jun 2017 at 10:06 Thomas Kluyver  wrote:

> On Tue, Jun 27, 2017, at 04:58 PM, Barry Warsaw wrote:
> > On Jun 25, 2017, at 11:33 AM, Nick Coghlan wrote:
> > >I'd favour "Participate" over any variant of "Contribute", as without
> > >context, "Contribute" makes me think of financial support in the
> > >crowdfunding/tip jar sense.
> >
> > "Participate" may mean two different things.
> >
> > * Here's the development home, with a repo and issue tracker,
> > contributions
> >   welcome!
> >
> > * Here's the mailing list or other forum where we discuss the future of
> >   Guido's Magical Mystery Time Machine.
>
> Perhaps this points to labelling URLs with nouns rather than verbs:
> things like 'mailing list', 'source code' or 'issue tracker' seem less
> ambiguous than 'participate' or 'contribute'.
>

I agree with Thomas on this one. Seeing a link that says "Participate" just
feels like it's missing an exclamation point and subtext saying I could
earn $2,000/week from it. ;)

Since this has turned into bikeshedding over names when we have a general
metadata solution, I've filed https://github.com/takluyver/flit/issues/116
and consider my question answered. :)
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Finishing up PEP 517

[Daniel Holth]

Is there a prototype implementation of pep 517 yet?

On Wed, Jun 28, 2017, 06:58 Robert Collins 
wrote:

>
>
> Re: returning magic strings to indicate exceptions. Please no. Just no.
> Have any pep build host add a small library to Python path with any symbols
> we want to define. Hardly an implementation hurdle.
>
> Rob
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] ANNOUNCE: Sunsetting of uploading to the legacy PyPI/TestPyPI

[Donald Stufft]

> On Jun 22, 2017, at 12:32 PM, Donald Stufft  wrote:
> 
> For TestPyPI the change to disable uploads to legacy will be made in the next
> couple of days, likely this weekend.


This is done now. Tomorrow we’ll deploy it to real PyPI for the day, but it 
will then be reverted until July 3rd.

—
Donald Stufft



___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Finishing up PEP 517

[Robert Collins]

Re: returning magic strings to indicate exceptions. Please no. Just no.
Have any pep build host add a small library to Python path with any symbols
we want to define. Hardly an implementation hurdle.

Rob
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Finishing up PEP 517

[Paul Moore]

On 28 June 2017 at 05:29, Nick Coghlan  wrote:
> On 28 June 2017 at 13:43, Nathaniel Smith  wrote:
>> I would say that there's only one required path, which is in-place.
>> (But the tree that they do the in-place build in might have a more or
>> less complicated history). It worries me that you seem to think that
>> build_sdist and build_wheel should be coupled like this... this
>> proliferation of cases and the reification of "out of tree builds" as
>> a special thing that's different from an in-tree build in a temporary
>> tree is already what worried me about prepare_wheel_input_files, and
>> now it seems to be spreading :-).
>
> I don't know what additional coupling you're seeing: the only coupling
> is that building a wheel directly from a VCS source tree and first
> exporting an sdist and then building a wheel from that *must give the
> same result* (modulo any problems related to reproducible builds, or
> the lack thereof). If a project can't meet that expectation, then
> their sdist generation is broken, since it clearly isn't exporting the
> necessary content to actually build the project properly.
>
> If you weren't aware of that inherent coupling, and are surprised by
> the fact that it's a constraint on publishing useful sdists, then I'd
> consider it a good thing that PEP 517 is now making it more explicit.

Note that the whole concept of "out of tree builds" is not something
theoretical - it comes directly from pip's requirement to be able to
do clean builds. So saying that tree->sdist->unpacked sdist is "just
another in-place build of a different tree" is missing the point,
which is that we need a mechanism to produce an effectively identical,
in the sense that it must result in the same wheel, copy of a tree -
and because we chose the sdist as the route for that, there are
constraints on the contents of a sdist.

I view those constraints as pretty much self evident, as I would be
extremely surprised if I had a source tree of *any* form for a
project, and I build a sdist from it and gave it to a friend, and when
we both built wheels and installed them, we had different installed
copies of the project.

The alternative would be to have a separate "produce a copy of this
tree that builds the same wheel" hook. And I thought we already went
round that loop, which is how we ended up deciding that the sdist was
our approach...

Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig