Re: [Distutils] PEP 517 again

I don't have any context here, but "return NotImplemented" is a very narrow idiom intended only for binary operators (e.g. __add__) when the interpreter should give the other operand a chance (e.g. __radd__) or use a default implementation. In pretty much any other context, if you have an

Re: [Distutils] PEP 517 again

Looks like Nick is on the losing side here, but we shall see. On Aug 25, 2017 8:28 PM, "Greg Ewing" wrote: > Oh, BDFL, will you settle whether we should raise an exception or return > Notimplemented? > > On Aug 25, 2017 8:28 PM, "Greg Ewing"

Re: [Distutils] Conditionless setup.py

On 2017-08-25 16:16:39 -0700 (-0700), Nathaniel Smith wrote: [...] > I've wondered if we should fork it, rename it "the obvious minimal > language", and release our own 1.0. And make it a toggleable option to configparser? ;) The basic format is pretty similar, granted TOML has a lot more

Re: [Distutils] PEP 517 again

Oh, BDFL, will you settle whether we should raise an exception or return Notimplemented? On Aug 25, 2017 8:28 PM, "Greg Ewing" wrote: xoviat wrote: > I mean how is opening a file different than attempting to build an sdist? > 1. Opening a file is a very common

Re: [Distutils] PEP 517 again

xoviat wrote: I mean how is opening a file different than attempting to build an sdist? 1. Opening a file is a very common operation. 2. Most file opens are expected to succeed, and if one doesn't, the appropriate place to deal with that is almost never at the site of the open call, but

Re: [Distutils] PEP 517 again

> I don't agree that exceptions are the way to do "things" in general. They're the way to so *some* things. The question is whether the thing we're talking about is one of those things. I mean how is opening a file different than attempting to build an sdist? open() could return true or false

Re: [Distutils] PEP 517 again

Nathaniel Smith wrote: I now think it should only be a defined return value for get_requires_for_build_sdist and build_sdist, and should have special "sorry I can't do that Dave" semantics that are different from e.g. a missing get_requires_for_build_sdist hook. I don't think there's anything

Re: [Distutils] Conditionless setup.py

On Fri, Aug 25, 2017 at 5:46 PM, xoviat wrote: > I personally do not understand the aversion to YAML. I mean yes, the > specification is more complicated, but it's also more popular and the YAML > files will not be complex enough for a C library to help that much. And > since

Re: [Distutils] PEP 517 again

xoviat wrote: I agree with Nick that exceptions are the way to do things in Python I don't agree that exceptions are the way to do "things" in general. They're the way to so *some* things. The question is whether the thing we're talking about is one of those things. The reasoning behind this

Re: [Distutils] PEP 517 again

Donald Stufft wrote: The thing being bubbled up is a backend accidentally calling an API that has yet to be implemented (an error that should be reported) being bubbled up and erroneously handled as the backend reporting it doesn't support making a sdist (not an error, son no traceback). To my

Re: [Distutils] Conditionless setup.py

I personally do not understand the aversion to YAML. I mean yes, the specification is more complicated, but it's also more popular and the YAML files will not be complex enough for a C library to help that much. And since it's more popular, people might even prefer specifying package metadata in a

Re: [Distutils] Conditionless setup.py

On Fri, Aug 25, 2017 at 1:00 PM, Jeremy Stanley wrote: > (The > community around it is sensitive to gender diversity issues and > wants to avoid acquiring more of a "brogrammer" image, so some of us > worry that any conspicuous TOML files checked into revision control >

Re: [Distutils] PEP 517 again

For the record, I agree with the proposals made in Nathaniel's last two emails. 2017-08-25 17:36 GMT-05:00 Nathaniel Smith : > On Fri, Aug 25, 2017 at 2:26 PM, xoviat wrote: > >> I'm more or less persuaded by Nathaniel's argument that the source > >> directory

Re: [Distutils] PEP 517 again

On Fri, Aug 25, 2017 at 2:26 PM, xoviat wrote: >> I'm more or less persuaded by Nathaniel's argument that the source >> directory shouldn't be on sys.path > > I do too. There should be an option in pyproject.toml to disable this > behavior though so that numpy can build itself.

Re: [Distutils] PEP 517 again

On Fri, Aug 25, 2017 at 2:17 PM, xoviat wrote: > Nathaniel: > > What do you think of the proposal regarding DistutilsUnsupportedOperation? So yeah, we could potentially say: 1) Every backend must have an attribute SdistBuildNotSupportedError, which is a type object subclassing

Re: [Distutils] PEP 517 again

On Fri, Aug 25, 2017, at 10:26 PM, xoviat wrote: > > I'm more or less persuaded by Nathaniel's argument that the source > > directory shouldn't be on sys.path> > I do too. There should be an option in pyproject.toml to disable this > behavior though so that numpy can build itself. I'm not sure

Re: [Distutils] PEP 517 again

> I'm more or less persuaded by Nathaniel's argument that the source directory shouldn't be on sys.path I do too. There should be an option in pyproject.toml to disable this behavior though so that numpy can build itself. 2017-08-25 16:21 GMT-05:00 Thomas Kluyver : > On

Re: [Distutils] PEP 517 again

On Fri, Aug 25, 2017, at 10:02 PM, xoviat wrote: > While we're waiting for others to respond, what are we going to do > with respect to the sys.path issue? I don't think there has been > discussion on that yet. I'm more or less persuaded by Nathaniel's argument that the source directory shouldn't

Re: [Distutils] PEP 517 again

Nathaniel: What do you think of the proposal regarding DistutilsUnsupportedOperation? 2017-08-25 16:13 GMT-05:00 Nathaniel Smith : > On Fri, Aug 25, 2017 at 9:49 AM, Thomas Kluyver > wrote: > > Can I gently ask everyone involved to consider whether the > >

Re: [Distutils] PEP 517 again

On Fri, Aug 25, 2017 at 9:49 AM, Thomas Kluyver wrote: > Can I gently ask everyone involved to consider whether the > notimplemented/error discussion is verging into bikeshedding > (http://bikeshed.org/)? > > The technical arguments I have seen so far are: > - The exception

Re: [Distutils] PEP 517 again

On 25 August 2017 at 18:02, xoviat wrote: > While we're waiting for others to respond, what are we going to do with > respect to the sys.path issue? I don't think there has been discussion on > that yet. > There was plenty of discussion. The summary is: - removing srcdir

Re: [Distutils] PEP 517 again

While we're waiting for others to respond, what are we going to do with respect to the sys.path issue? I don't think there has been discussion on that yet. 2017-08-25 15:54 GMT-05:00 Nathaniel Smith : > On Fri, Aug 25, 2017 at 1:51 PM, Thomas Kluyver >

Re: [Distutils] PEP 517 again

On Fri, Aug 25, 2017 at 1:51 PM, Thomas Kluyver wrote: > On Fri, Aug 25, 2017, at 09:50 PM, xoviat wrote: > > > Genius! > > > 1% inspiration, 99% frustration :-P This joke is so clever that I fear we may be forced to implement the solution after all, just to punish Thomas.

Re: [Distutils] PEP 517 again

On Fri, Aug 25, 2017, at 09:50 PM, xoviat wrote: > Genius! 1% inspiration, 99% frustration :-P ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 517 again

Genius! 2017-08-25 15:47 GMT-05:00 Thomas Kluyver : > On Fri, Aug 25, 2017, at 09:41 PM, xoviat wrote: > > There's no need to return an instance of the exception class. As long as > it is defined in the same name space as the hooks the front end will be > able to access it.

Re: [Distutils] PEP 517 again

On Fri, Aug 25, 2017, at 09:41 PM, xoviat wrote: > There's no need to return an instance of the exception class. As long > as it is defined in the same name space as the hooks the front end > will be able to access it. No, I meant NotImplementedError. As in: if i_cant_do_it: return

Re: [Distutils] PEP 517 again

There's no need to return an instance of the exception class. As long as it is defined in the same name space as the hooks the front end will be able to access it. On Aug 25, 2017 3:15 PM, "Thomas Kluyver" wrote: > What if hooks returned instances of the exception class?

Re: [Distutils] PEP 517 again

What if hooks returned instances of the exception class? That way it doesn't bubble up from internal code, it can carry a message, and we can all agree that it's a semantically terrible idea that doesn't fit with any conventions. Even I'm not sure if this is a serious suggestion. ;-) On Fri, Aug

Re: [Distutils] Conditionless setup.py

On 2017-08-25 14:00:25 +0100 (+0100), Paul Moore wrote: [...] > I'm not that familiar with those tools, but if they enable that > sort of use then that's great. I did get the impression that they > were for more complex/specialised use cases, though, whereas flit > (with PEP 517) is much more

Re: [Distutils] PEP 517 again

Do you mean in addition to the two lines proposed here? I envision the typical use case as attempting to do something that is required to build an sdist deep inside the backend, discovering that it cannot be done, and then raising the proposed exception. That's (other than the two lines for the

Re: [Distutils] PEP 517 again

It's silly to require every backend to write code to guard against possible issues when we can structure the API to prevent those issues. Sent from my iPhone > On Aug 25, 2017, at 3:04 PM, xoviat wrote: > > I agree with Nick that exceptions are the way to do things in

Re: [Distutils] PEP 517 again

I agree with Nick that exceptions are the way to do things in Python and with Donald that in general, Python's use of exceptions has caused problems. But I don't think that this forum is the correct place to discuss Python conventions, and so I would ordinarily say that we should just accept that

Re: [Distutils] PEP 517 again

The thing being bubbled up is a backend accidentally calling an API that has yet to be implemented (an error that should be reported) being bubbled up and erroneously handled as the backend reporting it doesn't support making a sdist (not an error, son no traceback). Sent from my iPhone > On

Re: [Distutils] PEP 517 again

The issue is about exceptions bubbling up to the interface level, not about crashing pip. For example, if some class raises notimplemented error and pip interprets that to mean it should call build_wheel. On Aug 25, 2017 1:23 PM, "Paul Moore" wrote: > On 25 August 2017 at

Re: [Distutils] PEP 517 again

On 25 August 2017 at 18:06, xoviat wrote: > Is pip going to fall back to building a wheel directly if any other error is > raised? That's what happens with setup.py install. If so, then it may be > fine if unexpected exceptions bubble up. Given that hooks need to be called in a

Re: [Distutils] PEP 517 again

> On Aug 25, 2017, at 1:06 PM, xoviat wrote: > > Is pip going to fall back to building a wheel directly if any other error is > raised? That's what happens with setup.py install. If so, then it may be fine > if unexpected exceptions bubble up. > I doubt it. It will likely

Re: [Distutils] PEP 517 again

Is pip going to fall back to building a wheel directly if any other error is raised? That's what happens with setup.py install. If so, then it may be fine if unexpected exceptions bubble up. On Aug 25, 2017 11:57 AM, "Donald Stufft" wrote: > > On Aug 25, 2017, at 12:49 PM,

Re: [Distutils] PEP 517 again

> On Aug 25, 2017, at 12:49 PM, Thomas Kluyver wrote: > > Can I gently ask everyone involved to consider whether the > notimplemented/error discussion is verging into bikeshedding > (http://bikeshed.org/ )? > > The technical arguments I have seen

Re: [Distutils] PEP 517 again

We could support both options on the frontend side. It's only a tiny bit of duplication in pip. On Aug 25, 2017 11:50 AM, "Thomas Kluyver" wrote: > Can I gently ask everyone involved to consider whether the > notimplemented/error discussion is verging into bikeshedding ( >

Re: [Distutils] PEP 517 again

Can I gently ask everyone involved to consider whether the notimplemented/error discussion is verging into bikeshedding (http://bikeshed.org/)? The technical arguments I have seen so far are: - The exception can include a message - The return value can't 'bubble up' from the internals of a hook

Re: [Distutils] PEP 517 again

By the way, what is the status on sys.path? On Aug 25, 2017 11:45 AM, "Donald Stufft" wrote: > > On Aug 25, 2017, at 12:38 PM, xoviat wrote: > > According to the documentation, NotImplemented isn't appropriate either, > as is for binary operations only.

Re: [Distutils] PEP 517 again

> On Aug 25, 2017, at 12:38 PM, xoviat wrote: > > According to the documentation, NotImplemented isn't appropriate either, as > is for binary operations only. There is no one value that's taylor made for > this situation, but an exception may be more appropriate as the

Re: [Distutils] PEP 517 again

According to the documentation, NotImplemented isn't appropriate either, as is for binary operations only. There is no one value that's taylor made for this situation, but an exception may be more appropriate as the underlying cause is probably an error. On Aug 25, 2017 11:11 AM, "Donald Stufft"

Re: [Distutils] PEP 517 again

> On Aug 24, 2017, at 10:52 AM, Nick Coghlan wrote: > > Aye, I do, and it should be "raise NotImplementedError('Explanation of > the failed check')" > > Rationale: > > - Python isn't C or Go, so we indicate failures with exceptions, not > error codes (NotImplemented is an

Re: [Distutils] Conditionless setup.py

On 25 August 2017 at 12:14, Jeremy Stanley wrote: > On 2017-08-25 10:50:11 +0100 (+0100), Paul Moore wrote: > [...] >> once PEP 517 is implemented and as flit gains popularity, I fully >> expect more and more projects to use a static data structure for >> their metadata

Re: [Distutils] Conditionless setup.py

On 2017-08-25 07:37:23 -0500 (-0500), Ian Stapleton Cordasco wrote: > Except that OpenStack frequently rejects outside use cases as I > learned as an OpenStack developer who tried to improve PBR. Sadly > it will never be seen as a global solution as long as that > continues Many projects

Re: [Distutils] Conditionless setup.py

It's important to realize that build is a Turing-complete activity. We write programs to build programs. Where setup.py gets in trouble is by making both the metadata and the build script the same thing, making it harder to reason about that metadata. That is why we are working towards being able

Re: [Distutils] Conditionless setup.py

Except that OpenStack frequently rejects outside use cases as I learned as an OpenStack developer who tried to improve PBR. Sadly it will never be seen as a global solution as long as that continues On Aug 25, 2017 6:32 AM, "Jeremy Stanley" wrote: > On 2017-08-25 10:50:11

Re: [Distutils] Fwd: Re: PEP 517 again

On 25 August 2017 at 17:47, Paul Moore wrote: > If anyone feels that it's *not* reasonable for users to expect "build > a wheel" and "build a sdist and build a wheel from that" to produce > the same results for a given source tree (assuming the backend > supports both

Re: [Distutils] Conditionless setup.py

On 2017-08-25 10:50:11 +0100 (+0100), Paul Moore wrote: [...] > once PEP 517 is implemented and as flit gains popularity, I fully > expect more and more projects to use a static data structure for > their metadata (flit.ini, specifically). This has also been possible for years already using

Re: [Distutils] Fwd: Re: PEP 517 again

On Fri, Aug 25, 2017, at 11:56 AM, Thomas Kluyver wrote: > Great, I think we're on the same page. I'm going to make a PR against > the PEP while I still remember what page it is. ;-) https://github.com/python/peps/pull/364 ___ Distutils-SIG maillist -

Re: [Distutils] Fwd: Re: PEP 517 again

On Fri, Aug 25, 2017, at 11:45 AM, Paul Moore wrote: > If it can't build a sdist then there's no opportunity for frontends to > fall back to sdist->wheel anyway, so that's not an issue[1]. > > It's only if sdist->wheel and direct wheel are both possible that > frontends have a choice, and I feel

Re: [Distutils] Fwd: Re: PEP 517 again

On 25 August 2017 at 11:16, Thomas Kluyver wrote: >> I repeat my earlier comment here - do we have any actual cases where >> we expect in-place wheel builds to *not* enforce the equivalence? > > Flit cannot strictly enforce it if it can't build an sdist: with the way > I've

Re: [Distutils] Fwd: Re: PEP 517 again

Thanks Paul, On Fri, Aug 25, 2017, at 10:45 AM, Paul Moore wrote: > I'd *also* expect that the wheel built (and hence what gets installed) > would be the same as what you'd get if the user added write > permissions and then ran the command. That's part of what I mean by > direct wheel and

Re: [Distutils] Conditionless setup.py

On 25 August 2017 at 09:36, Thomas Güttler wrote: > The setup.py of numpy looks big and complicated: > https://github.com/numpy/numpy/blob/master/setup.py > > I guess there are even more complicated setup.py files. > > Do you think it will be possible in the future

Re: [Distutils] Fwd: Re: PEP 517 again

On 25 August 2017 at 09:38, Thomas Kluyver wrote: > On Fri, Aug 25, 2017, at 08:47 AM, Paul Moore wrote: >> I've never cared about whether the backend modifies the source tree, >> only that the direct-wheel / sdist->wheel equivalence holds. > > If a user types 'pip install

Re: [Distutils] Conditionless setup.py

Hi Thomas! Have you seen Pipfile? It's something along those lines - a declarative specification of project data. :) github.com/pypa/pipfile Regards, Pradyun Gedam On Fri, Aug 25, 2017, 14:12 Thomas Güttler wrote: > The setup.py of numpy looks big and

[Distutils] Conditionless setup.py

The setup.py of numpy looks big and complicated: https://github.com/numpy/numpy/blob/master/setup.py I guess there are even more complicated setup.py files. Do you think it will be possible in the future to make setup.py conditionless (no "if", no "else", no function calls)? I mean that the

Re: [Distutils] Fwd: Re: PEP 517 again

On Fri, Aug 25, 2017, at 08:47 AM, Paul Moore wrote: > I've never cared about whether the backend modifies the source tree, > only that the direct-wheel / sdist->wheel equivalence holds. If a user types 'pip install .' in a directory where they don't have write permissions, what should happen?

Re: [Distutils] Fwd: Re: PEP 517 again

On 25 August 2017 at 06:54, Nick Coghlan wrote: > On 25 August 2017 at 14:33, xoviat wrote: >> Just this morning, Paul said the following: >> >> That step's the problem. If the frontend does that it can potentially >> be copying a lot of unneeded stuff (VCS