Re: [Distutils] Announcement: Pip 10 is coming, and will move all internal APIs

Nick: That's generally a good idea, but one significant problem that can occur is that the Python import system will cache certain libraries, people will run "pip install," and then they will expect such libraries to be available. I don't even know exactly how the caching for the import system

Re: [Distutils] Announcement: Pip 10 is coming, and will move all internal APIs

The short answer is that someone complained about the pip API not doing what they wanted it to do, so we broke the API to make it clear to everyone that the API is not something that should be depended on. 2017-10-20 17:53 GMT-05:00 Richard Jones : > Hiya Paul, > >

Re: [Distutils] Announcement: Pip 10 is coming, and will move all internal APIs

proaches are too risky, probably don't offer it in the pip > list output. > > --Noah > > > On Oct 20, 2017, at 11:43 AM, xoviat <xov...@gmail.com> wrote: > > > > A correct dry-run implementation will do about the same amount of work > as installing to a tem

Re: [Distutils] Announcement: Pip 10 is coming, and will move all internal APIs

r config management systems and if > not fixed in pip, will require continued use of internal APIs. I would > recommend just making pip list take a set of install-compatible > names/version patterns and apply that as a filter in a similar way to what > I've done there. > > --Noah &g

Re: [Distutils] Announcement: Pip 10 is coming, and will move all internal APIs

There's no dry-run functionality that I know of so far. However, you could use the following: pip install --prefix=tmpdir This command is actually about the same speed as a proper implementation, because we can't actually know what we're installing until we build the requirements. 2017-10-20

Re: [Distutils] Announcement: Pip 10 is coming, and will move all internal APIs

+1 on pre-release wheels. I've seen the process in action with SciPy, and it helped to catch at least one significant bug. 2017-10-20 8:30 GMT-05:00 Paul Moore : > On 20 October 2017 at 14:26, Matthew Brett > wrote: > > Thanks for the heads-up. > >

Re: [Distutils] Claim/remove pypi package named sc0ns

If I understand correctly, the guidelines say that its possible to remove/take over a package if the owner doesn't dispute it. If the owner disputes it, then I don't think it's possible. Please let me know whether this assumption is correct. 2017-10-10 10:35 GMT-05:00 Bill Deegan

[Distutils] Claiming Ownership of Existing Package

All: I would like to claim ownership of the "flint" package on pypi so that I can upload a new package with the same name. The existing project page states that it is abandoned. ___ Distutils-SIG maillist - Distutils-SIG@python.org

Re: [Distutils] Extracting distutils into setuptools

eypatching). 2017-09-30 20:14 GMT-05:00 Donald Stufft <don...@stufft.io>: > I think that the CPython builds a python executable, then uses that built > executable to finish the installation. > > > On Sep 30, 2017, at 9:11 PM, xoviat <xov...@gmail.com> wrote: > > It wou

Re: [Distutils] Extracting distutils into setuptools

It would be nice to know whether this information is correct, or whether I hold an invalid belief. 2017-09-30 20:09 GMT-05:00 xoviat <xov...@gmail.com>: > I have personally not built Python myself (though I've built many an > extension), but what I can say is that I got the ide

Re: [Distutils] Extracting distutils into setuptools

le rather badly. This is of course expected. However, the python Makefile itself depends on having a working local python interpreter, so when you break that you often break your build too." 2017-09-30 19:59 GMT-05:00 Donald Stufft <don...@stufft.io>: > > > On Sep 30, 2017, at 3:52 PM, xov

Re: [Distutils] Extracting distutils into setuptools

like pyproject.toml (other programming languages usually bootstrap themselves with previous versions of the language along with some associated build tools). 2017-09-29 22:43 GMT-05:00 Donald Stufft <don...@stufft.io>: > > > > On Sep 29, 2017, at 11:21 PM, xoviat <xov...@gmail.

Re: [Distutils] Extracting distutils into setuptools

I don't think writing shims for distutils is as easy as you make it sound. In fact, I'd venture to say that it's an intractable problem because of the difficulty of knowing the number of distutils hacks that are in the wild. 2017-09-29 22:15 GMT-05:00 Donald Stufft : > > > On

Re: [Distutils] Extracting distutils into setuptools

Distutils has many problems as you said, but by direct implication, if setuptools is "intimately tied" to distutils, then setuptools has these problems as well (and I think that it does). > I don’t really have a good answer for that. Probably it’s best to keep setuptools moving along as it’s

Re: [Distutils] Extracting distutils into setuptools

rote: > >> On 29 September 2017 at 07:42, Matthias Klose <d...@ubuntu.com> wrote: >> > On 27.09.2017 11:37, Nick Coghlan wrote: >> >> On 27 September 2017 at 12:30, xoviat <xov...@gmail.com> wrote: >> >>>> In short, I think your proposal is a

Re: [Distutils] Extracting distutils into setuptools

> So how do we get there? I would think a fork and merge of both setuptools and distutils would make sense. Preserve the building part of the API, so folks could simply replace the import line an their setup.py files to use the new tool. There's no need to even replace the line in setup.py.

Re: [Distutils] Extracting distutils into setuptools

That's actually an interesting idea though: for Python 3.7 distutils -> _distutils (and then setuptools is required for building). For/against? 2017-09-27 14:46 GMT-05:00 xoviat <xov...@gmail.com>: > No. Setuptools is what projects without a build_backend in pyproject.toml > get

Re: [Distutils] Extracting distutils into setuptools

No. Setuptools is what projects without a build_backend in pyproject.toml get. Not distutils. We should make it clear now that the distutils namespace belongs to setuptools except for when building cpython. On Sep 27, 2017 2:33 PM, "Ned Deily" wrote: > On Sep 27, 2017, at

Re: [Distutils] Extracting distutils into setuptools

/cc @jaraco 2017-09-27 11:34 GMT-05:00 xoviat <xov...@gmail.com>: > So since PEP 517 is going into setuptools anyway, we can > sys.path.insert(0, NEW_DISTUTILS_LOCATION) and then import distutils in the > interface before setup.py is loaded. Seems simple enough. > > 2017-

Re: [Distutils] Extracting distutils into setuptools

So since PEP 517 is going into setuptools anyway, we can sys.path.insert(0, NEW_DISTUTILS_LOCATION) and then import distutils in the interface before setup.py is loaded. Seems simple enough. 2017-09-27 11:27 GMT-05:00 Nick Coghlan : > On 27 September 2017 at 23:35, Donald

[Distutils] Extracting distutils into setuptools

This was a comment by @zooba (Steve Dower): > (FWIW, I think it makes *much* more sense for setuptools to fix this by simply forking all of distutils and never looking back. But since we don't live in that world yet, it went into distutils.) And here is my response: > Since you mention it, I

Re: [Distutils] string types for paths in PEP 517

+1 2017-09-05 3:21 GMT-05:00 Paul Moore : > On 5 September 2017 at 09:00, Thomas Kluyver wrote: > > I considered this. It's *potentially* a problem, but I think we should > > not try to deal with it for now: > > > > - Normally, temp files will go in

Re: [Distutils] PEP 517 again

Supposedly there is some meeting tomorrow concerning the wheel project that will determine the fate of dist_info. So that is why I bought it up. On Sep 4, 2017 9:00 PM, "Chris Jerdonek" <chris.jerdo...@gmail.com> wrote: > On Mon, Sep 4, 2017 at 6:41 PM, xoviat <x

Re: [Distutils] PEP 517 again

The PR that I am taking about is not for pip but for the wheel project. On Sep 4, 2017 8:19 PM, "Chris Jerdonek" <chris.jerdo...@gmail.com> wrote: > On Mon, Sep 4, 2017 at 6:08 PM, xoviat <xov...@gmail.com> wrote: > > In any case, we're going to need this for prep

Re: [Distutils] PEP 517 again

. 2017-09-04 19:51 GMT-05:00 xoviat <xov...@gmail.com>: > > The only reason I can think of that setuptools would need a dist_info > command would be to implement the PEP 517 prepare_wheel_metadata hook. > > Yes. That is absolutely correct. > > > But this hook is

Re: [Distutils] PEP 517 again

-05:00 Nathaniel Smith <n...@pobox.com>: > On Mon, Sep 4, 2017 at 5:09 PM, xoviat <xov...@gmail.com> wrote: > > Nathaniel: > > > > Pip requires egg_info to discover dependencies of source distributions so > > that it can build wheels all at once after downloading t

Re: [Distutils] PEP 517 again

Also if someone with pip write access could please discuss and hopefully merge my initial PR on pip, I would very much appreciate it. Paul seems to be short on time. 2017-09-04 19:09 GMT-05:00 xoviat <xov...@gmail.com>: > Nathaniel: > > Pip requires egg_info to discover depende

Re: [Distutils] PEP 517 again

t;n...@pobox.com>: > On Sun, Sep 3, 2017 at 11:14 AM, xoviat <xov...@gmail.com> wrote: > > Just an update for everyone here: > > > > 1. We're currently waiting on the implementation of the 'dist_info" > command > > in the wheel project. > > 2. Onc

Re: [Distutils] PEP 517 again

much more efficient release system than pip, I anticipate having a release of setuptools first and then we can switch pip over to requiring a newer setuptools via PEP 518. 2017-09-02 19:51 GMT-05:00 Chris Jerdonek <chris.jerdo...@gmail.com>: > On Sat, Sep 2, 2017 at 5:17 PM xoviat <

Re: [Distutils] PEP 541

I would actually like to transfer the "pywin32" project to Paul, Glyph, myself and friends because nothing has been uploaded there, but I thought it wasn't possible. Maybe it is? 2017-09-02 6:05 GMT-05:00 nassim daoud : > Hello, > > There is a friend of mine

Re: [Distutils] PEP 517 again

Whatever it was, removing it seems to have had no effect on the tests. I will remove it unless someone has an objection. 2017-09-02 18:26 GMT-05:00 xoviat <xov...@gmail.com>: > Donald, > > > This was your work in https://github.com/pypa/pip/pull/2169. > Unfortunately th

Re: [Distutils] PEP 517 again

Donald, This was your work in https://github.com/pypa/pip/pull/2169. Unfortunately the comments were quite sparse. 2017-09-02 18:25 GMT-05:00 xoviat <xov...@gmail.com>: > One more issue that has come up is that "--no-user-cfg" seems to be passed > to the egg_info invoc

Re: [Distutils] PEP 517 again

One more issue that has come up is that "--no-user-cfg" seems to be passed to the egg_info invocation if the "isolated" parameter is enabled. I don't understand what this does, but it is again not defined in the PEP 517 interface. Should we always pass this parameter or should we never pass it?

Re: [Distutils] PEP 517 again

I don't buy the argument that pip needs to keep separate caches for different implementations. According to the wheel specification, a wheel is valid for the Python implementations that it specifies. This is therefore a blatant violation by setuptools of an existing specification that, in theory,

Re: [Distutils] PEP 517 again

There are two points that I would note here: 1. setuptools handling of environment markers in wheels was actually broken until recently. 2. Even now, people still prefer runtime detection of environment markers to work around pip's upgrade behavior and old setuptools versions. There needs to be a

Re: [Distutils] PEP 517 again

Will do. Better to hash this out sooner than later. On Aug 31, 2017 12:36 AM, "Nathaniel Smith" <n...@pobox.com> wrote: > On Wed, Aug 30, 2017 at 9:56 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 31 August 2017 at 14:22, xoviat <xov...@gmail.com

Re: [Distutils] PEP 517 again

, is everyone okay with that? And does everyone understand the reason for this? 2017-08-30 18:29 GMT-05:00 xoviat <xov...@gmail.com>: > So while I was working on pip, I noticed a parameter called 'autobuilding' > in wheel.py. What this does (I think) is that if pip decides that it needs > to be

Re: [Distutils] PEP 517 again

backend for setuptools assume "py36" in python_tag 2017-08-29 18:51 GMT-05:00 Matthew Brett <matthew.br...@gmail.com>: > Hi, > > On Tue, Aug 29, 2017 at 8:30 PM, xoviat <xov...@gmail.com> wrote: > >> For me, using NotImplemented is a misuse of the sin

Re: [Distutils] PEP 517 again

> For me, using NotImplemented is a misuse of the singleton since I know what it's meant to be used for (and so I cringe every time I hear it brought up as a solution). I hate to reiterate too much, but I think that you are correct here: NotImplemented is not Pythonic. It's a complete hack that I

Re: [Distutils] PEP 517 again

> If so, let the trumpets sound, and the heralds declare that "return NotImplemented" is the way to do it. (I hope I've remembered Nathaniel's preference right ;-) For better or for worse, the trumpets seem to be sounding against this idea (Nathaniel seemed okay with whatever Donald and Nick

Re: [Distutils] PEP 517 again

> But I'm suspicious of the rationale that *there will be fewer frontends so they should have more responsibility*. To be fair, pip is currently struggling to keep up with project requirements as it is, which has caused some frustration in the community (not that the frustration isn't wrong, but

Re: [Distutils] PEP 517 again

Personally, my plan for the setuptools backend will be to build a source distribution (essentially using the command-line interface), extract into a tmpdir, and then build a wheel (essentially using the command line interface). So if pip calls build_sdist and then build_wheel, there will be two

Re: [Distutils] PEP 517 again

thony Risinger" <c...@anthonyrisinger.com> wrote: > On Sat, Aug 26, 2017 at 11:18 PM, xoviat <xov...@gmail.com> wrote: > >> > and they do not appear to receive the source or wheel directories. >> >> The source directory is the current directory, if I

Re: [Distutils] PEP 517 again

> and they do not appear to receive the source or wheel directories. The source directory is the current directory, if I am not mistaken. > This lets `build_*` focus purely on building things straight away. There is a difference between "no more reqs are needed to do X" and "no possible req will

Re: [Distutils] PEP 517 again

Nathaniel: Just to clarify, we're talking about returning none for the build function not the get requirements function. The get requirements function is always expected to succeed and is optional. If while the backend is discovering requirements it finds that it cannot build, then it can return

Re: [Distutils] PEP 517 again

With respect to this issue, if everyone told me that I was wrong then I would say I'm obviously wrong. But some people are saying one thing and other people are saying something else. On Aug 26, 2017 5:03 PM, "xoviat" <xov...@gmail.com> wrote: > As I said, I don't care

Re: [Distutils] PEP 517 again

not in and of itself packaging related. The clear way to resolve this was to get a pronouncement. On Aug 26, 2017 4:56 PM, "Nathaniel Smith" <n...@pobox.com> wrote: > On Sat, Aug 26, 2017 at 2:06 PM, xoviat <xov...@gmail.com> wrote: > > I also think that Guido prett

Re: [Distutils] PEP 517 again

Nathaniel: We're not talking about signaling failure in get_requires* we're talking about signaling failure in build*. On Aug 26, 2017 3:42 PM, "Nathaniel Smith" wrote: > On Sat, Aug 26, 2017 at 12:54 PM, Paul Moore wrote: > > On 26 August 2017 at 20:17,

Re: [Distutils] PEP 517 again

I also think that Guido pretty much ruled out Notimplemented. On Aug 26, 2017 4:04 PM, "xoviat" <xov...@gmail.com> wrote: > Why does the frontend need to know why an sdist was not created? > > I was of the opinion that such a distinction is not necessary because > bu

Re: [Distutils] PEP 517 again

Why does the frontend need to know why an sdist was not created? I was of the opinion that such a distinction is not necessary because building a source distribution doesn't take that much time. However Donald thought that there needed to be a distinction because of the wasted time in attempting

Re: [Distutils] PEP 517 again

The current PEP requires that build_sdist return the basename of the sdist. So forgetting a return statement is not an option unless people really don't read the PEP. On Aug 26, 2017 2:18 PM, "Nathaniel Smith" wrote: > [removed Guido from CC] > > On Aug 26, 2017 02:29, "Paul

Re: [Distutils] PEP 517 again

Should probably take Guido out of this email chain now. And does everyone agree with what Nathaniel said on sys.path? On Aug 26, 2017 11:00 AM, "Daniel Holth" <dho...@gmail.com> wrote: I'm bored with that On Sat, Aug 26, 2017, 11:59 xoviat <xov...@gmail.com> wrote:

Re: [Distutils] PEP 517 again

Is everyone on board with that? On Aug 26, 2017 4:29 AM, "Paul Moore" wrote: > On 26 August 2017 at 03:17, Guido van Rossum wrote: > > In pretty much any other context, if you have an operation that returns > an > > regular value or an error value, the

Re: [Distutils] PEP 517 again

28 PM, "Greg Ewing" <greg.ew...@canterbury.ac.nz> 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 operation. > > 2. Most file opens are expected to succeed,

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" <greg.ew...@canterbury.ac.nz> wrote: xoviat wrote: > I mean how is opening a file different than attempting to build an sdist? > 1. Opening a

Re: [Distutils] PEP 517 again

nd my opinion is that it would. The fact that Nick, who I think is the only core developer here, immediately jumped on this issue confirms my suspicions here. 2017-08-25 20:00 GMT-05:00 Greg Ewing <greg.ew...@canterbury.ac.nz>: > xoviat wrote: > >> I agree with Nick that exce

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] 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 <n...@pobox.com>: > On Fri, Aug 25, 2017 at 2:26 PM, xoviat <xov...@gmail.com> wrote: > >> I'm more or less persuaded by Nathaniel's argument that t

Re: [Distutils] PEP 517 again

.me.uk>: > 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 arg

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

luyver.me.uk> > 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 punis

Re: [Distutils] PEP 517 again

Genius! 2017-08-25 15:47 GMT-05:00 Thomas Kluyver <tho...@kluyver.me.uk>: > 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 b

Re: [Distutils] PEP 517 again

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] PEP 517 again

don...@stufft.io>: > 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 <xov...@gmail.com> wrote: > > I agree with Nick that

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

; On 25 August 2017 at 18:06, xoviat <xov...@gmail.com> 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. > >

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

ntics is going to go anywhere: they > are both reasonable ways for the backend to reply "sorry, Dave, I can't do > that". > > On Fri, Aug 25, 2017, at 05:38 PM, xoviat wrote: > > According to the documentation, NotImplemented isn't appropriate either, > as is for binary o

Re: [Distutils] PEP 517 again

By the way, what is the status on sys.path? On Aug 25, 2017 11:45 AM, "Donald Stufft" <don...@stufft.io> wrote: > > On Aug 25, 2017, at 12:38 PM, xoviat <xov...@gmail.com> wrote: > > According to the documentation, NotImplemented isn't appropriate either,

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] Fwd: Re: PEP 517 again

Okay, but I would like to hear Paul's response to that first. On Aug 25, 2017 12:54 AM, "Nick Coghlan" <ncogh...@gmail.com> wrote: > On 25 August 2017 at 14:33, xoviat <xov...@gmail.com> wrote: > > Just this morning, Paul said the following: > > > > Th

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

And one more thing: it would probably be prescient to require a get_backend_info hook that returns the name and url of the backend so that pip can direct people where to file bugs when there are problems. On Aug 24, 2017 11:52 PM, "xoviat" <xov...@gmail.com> wrote: > Act

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

Actually after reading the email that Nathaniel referenced, I disagree with Nick's position on in-tree builds. It's absolutely necessary because the tree may be read only and it's enforceable by pip through a simple recursive list. On Aug 24, 2017 11:33 PM, "xoviat" <xov...@gma

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

...@pobox.com> wrote: > On Thu, Aug 24, 2017 at 9:17 PM, xoviat <xov...@gmail.com> wrote: > > > I'm *not* OK with banning in-tree builds in the spec, since that's > > > both unnecessary and unenforceable > > > > Well then either we can trust the backend or

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

I'm *not* OK with banning in-tree builds in the spec, since that's both unnecessary and unenforceable Well then either we can trust the backend or we cannot. If we can, then this is both necessary and enforceable. If not, then we're back to pip copying files. You can't make and argument that it's

Re: [Distutils] PEP 517 again

In case anyone is interested, here is a mostly correct implementation of PEP 517 based on the behavior discussed here: https://github.com/pypa/setuptools/pull/1039/files#diff-522bd9826e33902f7f58bd003c6a370c As I said, there are a few items to be worked on still, but I really don't think that

Re: [Distutils] PEP 517 again

Nathaniel: Are you okay with what has been proposed? On Aug 24, 2017 7:29 PM, "Nathaniel Smith" wrote: > On Thu, Aug 24, 2017 at 7:52 AM, Nick Coghlan wrote: > >>> - I don't understand how out-of-tree builds and prepare_build_metadata > >>> are supposed to

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

The current proposal is to remove build_dir and leave it up to the backend. On Aug 24, 2017 7:07 PM, "Greg Ewing" wrote: > Paul Moore wrote: > >> 4. The point of all this is that the definition of build_directory >> says "If build_directory is None, the backend may

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

Actually I submitted a compliant PR 3 months ago when the PEP was first marked as accepted. Then it was marked as draft and I thought that I would just wait for distutils-sig to handle it. And then I came over here to find what was going on. On Aug 24, 2017 5:33 PM, "xoviat" <xov

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

I'm handling the setuptools backend. I will make sure that it complies with the clean directory. On Aug 24, 2017 5:30 PM, "Paul Moore" wrote: > On 24 August 2017 at 20:00, Thomas Kluyver wrote: > > So for the time being, I'd prefer to say that the

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

-- Forwarded message -- From: xoviat <xov...@gmail.com> Date: 2017-08-24 14:26 GMT-05:00 Subject: Re: [Distutils] Fwd: Re: PEP 517 again To: Thomas Kluyver <tho...@kluyver.me.uk> And also, are Nick and Paul okay with this? 2017-08-24 14:24 GMT-05:00 xoviat <x

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

So in summary: - NotImplementedError - Remove build_dir and specify that no modifications can be made to the source directory On the third issue: I understand where Nathaniel is coming from in regards to sys.path. But there should at least be an option for this because of for example, numpy:

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

> It looks like a lot of trouble for a feature that is designed to solve a problem for a very thin intersection of the Venn diagram of people who: For the record, I don't agree at all that build_wheel_incremental should be specified here. The suggestion is simply a compromise that I can tolerate

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

To be clear, is everyone okay with the following? build_wheel(wheel_directory, config_settings=None, metadata_directory=None): [REQUIRED] build_wheel_incremental(wheel_directory, config_settings=None, metadata_directory=None): [OPTIONAL] I still think that the frontend should not provide a

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

> For the same reason you would ever ask for incremental builds, to more quickly iterate while hacking, imagining that you are using the PEP 517 interface to develop, perhaps to have a uniform interface to patch something when you are not familiar with exactly the build system it uses. And so I

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

If the entire idea of copying out-of-tree is to work around setuptools deficiencies, then perhaps it would be a better idea to push this onto the setuptools build backend rather than bring these problems into PEP 517? 2017-08-24 10:32 GMT-05:00 xoviat <xov...@gmail.com>: > May I

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

May I ask what is wrong *in principle* with the setuptools "build" folder (other than the fact that it does not contain all tree changes)? 2017-08-24 10:27 GMT-05:00 xoviat <xov...@gmail.com>: > That is actually the first time that build_dir makes sense to me now. > Thank

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

That is actually the first time that build_dir makes sense to me now. Thank you. 2017-08-24 10:24 GMT-05:00 Paul Moore <p.f.mo...@gmail.com>: > On 24 August 2017 at 16:20, xoviat <xov...@gmail.com> wrote: > >> I *do* care about telling backends we don't want "dif

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

il.com>: > On 24 August 2017 at 16:15, xoviat <xov...@gmail.com> wrote: > >> 2. I'm not completely clear on how pip's implementation will work - I > > think the intention is to always build a sdist and build a wheel from > > that, unless the backend reports it can't

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

> I don't recall you having said "we do sdist->wheel then fall back to requesting wheels directly" You're correct. I did not say that because build_sdist is required. 2017-08-24 10:21 GMT-05:00 Paul Moore <p.f.mo...@gmail.com>: > On 24 August 2017 at 16:15, xoviat

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

> I *do* care about telling backends we don't want "different results from those that would be obtained by exporting an sdist first". I completely agree with this statement, but I don't believe that it can or should be accomplished with this parameter. Let me just quote the process that I

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

> 2. I'm not completely clear on how pip's implementation will work - I think the intention is to always build a sdist and build a wheel from that, unless the backend reports it can't build a sdist, in which case we ask it to build a wheel directly. This was the exact process that I proposed, but

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

Thomas, I did not receive the last message. On Aug 24, 2017 9:31 AM, "Thomas Kluyver" <tho...@kluyver.me.uk> wrote: > On Thu, Aug 24, 2017, at 03:29 PM, xoviat wrote: > > I understand that, but what I disagree with is modifying build_wheel to > make up for a l

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

I understand that, but what I disagree with is modifying build_wheel to make up for a lack of consensus on editable installs. On Aug 24, 2017 9:27 AM, "Thomas Kluyver" <tho...@kluyver.me.uk> wrote: > On Thu, Aug 24, 2017, at 03:05 PM, xoviat wrote: > > During dev

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

cache. And there is also nothing preventing pip from caching the temporary directory, which may contain build artifacts. On Aug 24, 2017 8:41 AM, "xoviat" <xov...@gmail.com> wrote: > -- Forwarded message ------ > From: "xoviat" <xov...@gmail.com>

[Distutils] Fwd: Re: PEP 517 again

-- Forwarded message -- From: "xoviat" <xov...@gmail.com> Date: Aug 24, 2017 8:39 AM Subject: Re: [Distutils] PEP 517 again To: "Thomas Kluyver" <tho...@kluyver.me.uk> Cc: That's actually the general argument against exceptions and why golang do

Re: [Distutils] PEP 517 again

I mean is this golang or Python? In Python, you raise notimplementederror. On Aug 24, 2017 8:17 AM, "Thomas Kluyver" wrote: > Nathaniel seems to be busy with other things at the moment, so I hope he > won't mind me passing on this list of things he'd like to resolve with >

Re: [Distutils] PEP 517: Bootstrapping setuptools

pendencies to bootstrap itself? 2017-08-22 13:50 GMT-05:00 Jim Fulton <j...@jimfulton.info>: > Oh, gawd. From now on, someone will have to say buildout 3 times before I > appear. > > On Tue, Aug 22, 2017 at 2:06 PM, xoviat <xov...@gmail.com> wrote: > >> So are we

Re: [Distutils] PEP 517: Bootstrapping setuptools

So are we going for a "primarily isolation" approach then where builds are only isolated on the first level, but subsequent levels share the same build environment? 2017-08-22 10:23 GMT-05:00 Jim Fulton : > I didn't mention (nor do I recall anyone mentioning) venvs. > > Jim

Re: [Distutils] PEP 517: Bootstrapping setuptools

have a stable API. 2017-08-21 16:27 GMT-05:00 Jim Fulton <j...@jimfulton.info>: > > > On Mon, Aug 21, 2017 at 5:17 PM, xoviat <xov...@gmail.com> wrote: > >> Of course, to be frank, the principle failure with this plan is that >> third-party tools (buildout, os

  1   2   >