On Mon, 28 Jan 2019 at 09:04, Paul Moore wrote:
> On Sun, 27 Jan 2019 at 21:02, Thomas Kluyver wrote:
> > On Sun, Jan 27, 2019, at 7:47 PM, Paul Moore wrote:
> > > What is more difficult is the question of whether the PEP should
> > > change. As Chris pointed out, the previous discussion ended up
On Mon, 28 Jan 2019 at 2:35 AM, Thomas Kluyver wrote:
> On Sun, Jan 27, 2019, at 7:47 PM, Paul Moore wrote:
> > What is more difficult is the question of whether the PEP should
> > change. As Chris pointed out, the previous discussion ended up saying
> > that the build directory should not be on
On Sun, 27 Jan 2019 at 21:02, Thomas Kluyver wrote:
>
> On Sun, Jan 27, 2019, at 7:47 PM, Paul Moore wrote:
> > What is more difficult is the question of whether the PEP should
> > change. As Chris pointed out, the previous discussion ended up saying
> > that the build directory should not be on s
> -Original Message-
> From: Antonio Cavallo
> Sent: Sunday, January 27, 2019 5:05 PM
> To: Alex Walters
> Subject: Re: [Distutils] unifying package formats
>
> I don't think they serve a much different scope after al:l both uncompress
> files under a filesystem. There are difference
On Sun, Jan 27, 2019, at 7:47 PM, Paul Moore wrote:
> What is more difficult is the question of whether the PEP should
> change. As Chris pointed out, the previous discussion ended up saying
> that the build directory should not be on sys.path, but acknowledged
> that mandating that might cause iss
I guess this depends on how explicit you wan to be. PEP 517 is not enabled
unconditionally, only when the project root contains pyproject.toml. The
problem is that other projects (unrelated to packaging) take advantage of the
file format’s existence, resulting in people “buy in” the situation
u
This is more an argument to not use pep-517 unless people explicitly
specify the backend, at which point they acknowledge to buy in that the cwd
is not on sys path (and they need to alter their packaging code
accordingly).
On Sun, 27 Jan 2019, 20:31 Tzu-ping Chung Yes, of course people can. I thi
Yes, of course people can. I think the problem is that common Python
installations defaults to adding the cwd into sys.path, so people expect this
to “just work”. A PEP 517 not doing it is not intuitive unless you follow
Python packaging closely, and most would simply assume pip is broken.
(In
On Sun, 27 Jan 2019 at 14:39, Thomas Kluyver wrote:
> I think the rule about the CWD not being on sys.path only applies to loading
> a proper PEP 517 build backend when that's specified in pyproject.toml.
I'm not entirely sure what you're intending when you refer to a
"proper PEP 517 build backe
The possibility of doing it in setuptools is discussed extensively in
the threads, but a lot of us are going off of half-remembered
discussions, so it's probably a good idea to get a central "agenda" of
the things we want to resolve and create a new thread for discussion in
the discourse.
Items I
I haven't read those discussions in full (sorry to be lazy, but there's
quite a lot there), but my initial take is that the rule doesn't apply
to running setup.py scripts, where there's a greater need for backward
compatibility. I think the rule about the CWD not being on sys.path only
applies to l
For those of you who participated in the PEP 517 discussion during the
summer of 2017 (just prior to its provisional acceptance), I want to flag
that one of the issues discussed back then has now resurfaced for
discussion. This is because the feature was turned on by default in pip's
latest release
12 matches
Mail list logo
