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 wor
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,
>
> There's a bunch of tooling out
, probably don't offer it in the pip
> list output.
>
> --Noah
>
> > On Oct 20, 2017, at 11:43 AM, xoviat wrote:
> >
> > A correct dry-run implementation will do about the same amount of work
> as installing to a temporary directory right now. In the future, t
agement 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
>
>
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 12:
+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.
> >
> > Will y'all be doing a PyPI pre-release so w
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 :
> Greetings,
>
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
https://mail.python.
enance (no monkeypatching).
2017-09-30 20:14 GMT-05:00 Donald Stufft :
> 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 wrote:
>
> It would be nice to know whether this
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 :
> I have personally not built Python myself (though I've built many an
> extension), but what I can say is that I got the idea from Larry Hastings.
er 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 :
>
>
> On Sep 30, 2017, at 3:52 PM, xoviat wrote:
>
&g
installed with
something 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 :
>
>
> > On Sep 29, 2017, at 11:21 PM, xoviat wrote:
&g
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 Sep 29, 2017, at 5:1
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 doing
07:42, Matthias Klose wrote:
>> > On 27.09.2017 11:37, Nick Coghlan wrote:
>> >> On 27 September 2017 at 12:30, xoviat wrote:
>> >>>> In short, I think your proposal is a good one, but how can we
>> allocate
>> >>>> manpower?
>
> 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. Setupt
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 :
> No. Setuptools is what projects without a build_backend in pyproject.toml
> get. Not distutils. We
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 13:31, Steve Dower wro
/cc @jaraco
2017-09-27 11:34 GMT-05:00 xoviat :
> 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:
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 Stufft wrote:
> > I sus
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 agr
+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 /tmp - so it should be fine to
> > construct p
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" wrote:
> On Mon, Sep 4, 2017 at 6:41 PM, xoviat wrote:
> > The PR that I am taking about
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" wrote:
> On Mon, Sep 4, 2017 at 6:08 PM, xoviat wrote:
> > In any case, we're going to need this for prepare_metadata, so the
> question
> > you sh
wheel PR and do a release.
2017-09-04 19:51 GMT-05:00 xoviat :
> > 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 opt
4 GMT-05:00 Nathaniel Smith :
> On Mon, Sep 4, 2017 at 5:09 PM, xoviat wrote:
> > Nathaniel:
> >
> > Pip requires egg_info to discover dependencies of source distributions so
> > that it can build wheels all at once after downloading the requirements.
> I
> > need
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 :
> Nathaniel:
>
> Pip requires egg_info to discover dependencies of source distrib
:
> On Sun, Sep 3, 2017 at 11:14 AM, xoviat 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. Once that is done we can switch pip o
acob has a
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 :
> On Sat, Sep 2, 2017 at 5:17 PM xoviat wrote:
>
>> Whateve
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 wondering, if abandoned PyPI projects
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 :
> Donald,
>
>
> This was your work in https://github.com/pypa/pip/pull/2169.
> Unfortunately the comments were quite sparse.
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 :
> One more issue that has come up is that "--no-user-cfg" seems to be passed
> to the egg_info invocation if the "i
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?
20
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, s
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 p
Will do. Better to hash this out sooner than later.
On Aug 31, 2017 12:36 AM, "Nathaniel Smith" wrote:
> On Wed, Aug 30, 2017 at 9:56 PM, Nick Coghlan wrote:
> > On 31 August 2017 at 14:22, xoviat wrote:
> >> Again, let me repeat that: wheels generated usin
everyone okay with that? And does everyone
understand the reason for this?
2017-08-30 18:29 GMT-05:00 xoviat :
> 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 e
ld the PEP 517 backend for setuptools assume "py36" in python_tag
2017-08-29 18:51 GMT-05:00 Matthew Brett :
> Hi,
>
> On Tue, Aug 29, 2017 at 8:30 PM, xoviat wrote:
> >> For me, using NotImplemented is a misuse of the singleton since I know
> >> what it
> 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
> 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 thoug
> 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 I
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 sou
;C Anthony Risinger"
wrote:
> On Sat, Aug 26, 2017 at 11:18 PM, xoviat wrote:
>
>> > and they do not appear to receive the source or wheel directories.
>>
>> The source directory is the current directory, if I am not mistaken.
>>
>
> Oh right right
> 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
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 a
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" wrote:
> As I said, I don't care what the particu
lly 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" wrote:
> On Sat, Aug 26, 2017 at 2:06 PM, xoviat wrote:
> > I also think that Guido pretty much ruled out Notimplemented.
>
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, Nathaniel Smith wrote:
> >> Eh... I wo
I also think that Guido pretty much ruled out Notimplemented.
On Aug 26, 2017 4:04 PM, "xoviat" 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
> building a source distribu
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 t
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 Moore" wrote:
>
> O
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" wrote:
I'm bored with that
On Sat, Aug 26, 2017, 11:59 xoviat wrote:
> Is everyone on board with that?
>
>
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 error value should be None.
> (Exceptions
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" wrote:
>
> xo
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 operation.
2.
be an exception to the norms
of Python, and 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 :
> xoviat wrote:
>
>> I agree with Nick that e
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
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
> >> director
, 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
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
> > notimplemented/error discussion is ver
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
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 i
t 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 25, 2
:
> 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 d
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 t
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 18:06,
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, Thomas Kluyver wrote:
g 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 bina
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. There is n
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"
Okay, but I would like to hear Paul's response to that first.
On Aug 25, 2017 12:54 AM, "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 do
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" wrote:
> Actually after reading t
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" wr
t; wrote:
> On Thu, Aug 24, 2017 at 9:17 PM, xoviat 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 we cannot. If we can, then
&
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
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 it
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 interact.
> >
> > They don't, since t
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 do an 'in place'
>> build whic
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" wro
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 build_wheel() hook
> should
> > not create or m
-- Forwarded message --
From: xoviat
Date: 2017-08-24 14:26 GMT-05:00
Subject: Re: [Distutils] Fwd: Re: PEP 517 again
To: Thomas Kluyver
And also, are Nick and Paul okay with this?
2017-08-24 14:24 GMT-05:00 xoviat :
> So in summary:
> - NotImplementedError
>
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:
nump
> 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
b
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 build
> 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
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 :
> May I ask what is wrong *in princi
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 :
> That is actually the first time that build_dir makes sense to me now.
> Thank you.
>
> 2017-08-2
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 :
> On 24 August 2017 at 16:20, xoviat wrote:
> >> I *do* care about telling backends we don't want "different
> > results from those that would
4 August 2017 at 16:15, xoviat 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 build a sdist, in which case
&
> 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 :
> On 24 August 2017 at 16:15, xoviat wrote:
> >&
> 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 propose
> 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
Thomas,
I did not receive the last message.
On Aug 24, 2017 9:31 AM, "Thomas Kluyver" 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 lack of consensus on editab
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" wrote:
> On Thu, Aug 24, 2017, at 03:05 PM, xoviat wrote:
>
> During development, you want to use an edit
27;t care about
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" wrote:
> -- Forwarded message --
> From: "xoviat"
> Date: Aug 24, 2017 8:39 AM
&
-- Forwarded message --
From: "xoviat"
Date: Aug 24, 2017 8:39 AM
Subject: Re: [Distutils] PEP 517 again
To: "Thomas Kluyver"
Cc:
That's actually the general argument against exceptions and why golang
doesn't have them. I have not seen notimplemente
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
> the draft PEP. I'll qu
ire external dependencies to bootstrap itself?
2017-08-22 13:50 GMT-05:00 Jim Fulton :
> 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 wrote:
>
>> So are we going for a "primarily isolati
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
>
>
> On Tue, Aug 22,
ts do not have
a stable API.
2017-08-21 16:27 GMT-05:00 Jim Fulton :
>
>
> On Mon, Aug 21, 2017 at 5:17 PM, xoviat wrote:
>
>> Of course, to be frank, the principle failure with this plan is that
>> third-party tools (buildout, os packagers) will not be compliant with PEP
1 - 100 of 113 matches
Mail list logo