Folks,
Can we get these issues sorted before pip 10 so that the pip committers will
accept my PR addressing the horrible easy_install behavior?
Regards,
xoviat
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman
At this point, I can only offer implementations as I have been attempting
to do (some of which are outdated because the PEP has changed), but I
cannot make anyone pay attention to or accept my pull requests and it seems
I cannot accelerate the discussion here.
2017-08-18 14:08 GMT-05:00 xoviat
Thomas:
What are the specific issues that need to be worked out?
Regards,
xoviat
2017-08-18 3:09 GMT-05:00 Thomas Kluyver <tho...@kluyver.me.uk>:
> On Fri, Aug 18, 2017, at 07:09 AM, Nick Coghlan wrote:
> > The other aspect I'm not clear on is whether or not b
hub.com/takluyver/flit/tree/toml-config
>
>
> On Fri, Aug 18, 2017, at 06:27 PM, Daniel Holth wrote:
>
> Apart from the issues, can we get some prototype implementations?
>
> On Fri, Aug 18, 2017, 13:24 xoviat <xov...@gmail.com> wrote:
>
> Thomas:
>
>
> What are the sp
I assume that the outstanding issues mentioned are related to sys.path in
the build tree. My view on that is the following: the build frontend should
be responsible using any mechanism that it chooses for invoking the build
backend, which must be imported with '' at the front of sys.path. This
rks with
appropriate fallbacks to verify setuptools support and compliance, then
it's not the end of the world if the packages are still built and installed
correctly.
2017-08-19 16:48 GMT-04:00 Paul Moore <p.f.mo...@gmail.com>:
> On 19 August 2017 at 21:30, xoviat <xov...@gmail.com>
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
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
I'm still not convinced, but this PEP has been WIP for too long. I think it
should be marked Accepted.
On Aug 17, 2017 9:51 PM, "Nick Coghlan" wrote:
> On 18 August 2017 at 02:05, 12345 67890 wrote:
> > After reviewing the PEP, I personally feel that it
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
> 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
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
+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
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
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
-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
.
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
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
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
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
/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-
> 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.
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
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
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
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
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
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.
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
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
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
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>
> 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
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
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
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
> 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
> 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
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
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
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
-- 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
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
>
> 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
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:
> 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
-- 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
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
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
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
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
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
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
Previously, the attempt to move setuptools off of vendored dependencies
failed because it was not done correctly: install_requires was set to the
vendored dependencies but not setup_requires, which would have been
required to correctly specify dependencies. However, setup_requires would
have
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
517 even after it is adopted, and will then complain about having to update
their build systems.
2017-08-21 16:05 GMT-05:00 xoviat <xov...@gmail.
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
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
.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
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
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
...@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
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
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
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
> >
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
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,
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
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:
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
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
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
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
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,
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
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
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
> 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
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
> 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
> 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
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
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
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
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
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
; 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.
>
>
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"
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
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,
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,
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
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
Ah the joy of Python 2.7; it seems I've forgotten its perils: unloading is
not possible which means that we would need to come up with another
solution to this problem. Perhaps setting aside a namespace for the build
frontend in the subprocess?
2017-08-19 14:23 GMT-04:00 xoviat <xov...@gmail.
button anyone can press to make it go quickly.
>
> Thomas
>
>
>
>
> On Fri, Aug 18, 2017, at 08:17 PM, xoviat wrote:
>
> At this point, I can only offer implementations as I have been attempting
> to do (some of which are outdated because the PEP has changed), but
Daniel Holth <dho...@gmail.com>:
> It's probably a tiny wrapper running the hook in its own subprocess.
> Probably few modules loaded.
>
> On Sat, Aug 19, 2017, 14:31 xoviat <xov...@gmail.com> wrote:
>
>> Ah the joy of Python 2.7; it seems I've forgotten its perils: u
Excuse me, but what I meant to say is that sys.path would be adjusted after
the subprocess was loaded (in my implementation I adjust sys.path and
os.environ['PYTHONPATH']).
2017-08-19 16:22 GMT-04:00 xoviat <xov...@gmail.com>:
> Yes, it probably is. But then again, I assumed that it wa
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
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?
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
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
1 - 100 of 113 matches
Mail list logo