On Wed, 20 Feb 2019 at 22:40, Alex Walters wrote:
>
> I have 2 main concerns about PEP 582 that might just be me misunderstanding
> the pep.
>
> My first concern is the use of CWD, and prepending ./_pypackages_ for
> scripts. For example, if you were in a directory with a _pypackages_
>
I have 2 main concerns about PEP 582 that might just be me misunderstanding
the pep.
My first concern is the use of CWD, and prepending ./_pypackages_ for
scripts. For example, if you were in a directory with a _pypackages_
subdirectory, and had installed the module "super.important.module". My
> On 20/2/2019, at 20:38, Alex Walters wrote:
>
> I have 2 main concerns about PEP 582 that might just be me misunderstanding
> the pep.
>
> My first concern is the use of CWD, and prepending ./_pypackages_ for
> scripts. For example, if you were in a directory with a _pypackages_
>
I like the pep at first glance. I have long thought that virtualenv was a
weird solution to an artificial problem notwithstanding that all
programming problems are artificial. Virtualenv looks good only because a
global interpreter centric environment is bad. A program centric
alternative is
I'd caution against folks getting too worked up about PEP 582. I know it's
been getting a lot of attention on social media recently, but, it's a draft
that hasn't even been submitted for discussion yet. Most PEPs at this stage
never end up going anywhere. And in general, when people start digging
On 20Feb.2019 0556, Nathaniel Smith wrote:
> I wonder if we should stick a header on the PEP draft saying something
> like this? There's a lot of scattershot responses happening and I think
> a lot of the people reacting are lacking context.
I agree, I think given the amount of attention it's
On 20Feb2019 0803, Dan Ryan wrote:
One final thing this enables as far as I understand is a sort of npm-like
option for ignoring resolution conflicts and simply performing a sort of nested
installation of subdependencies inside a top level dependency’s __pypackages__
folder. So if you did
On 20Feb2019 0831, Nathaniel Smith wrote:
Yeah, __pypackages__ has no way to handle scripts, and also no way to
access packages when you're running from a directory. Pipenv already
handles both of these cases fine today, so I'm not sure how having
__pypackages__ several years from now could
On Wed, Feb 20, 2019 at 8:49 AM Steve Dower wrote:
>
> On 20Feb2019 0831, Nathaniel Smith wrote:
> > Yeah, __pypackages__ has no way to handle scripts, and also no way to
> > access packages when you're running from a directory. Pipenv already
> > handles both of these cases fine today, so I'm
On 20Feb.2019 0533, Tzu-ping Chung wrote:
> As one of the Pipenv maintainers, however, it is my personal opinion that this
> PEP would not be end up in the “yet another standard” situation, but even be
> beneficial to Pipenv, if done correctly.
>
> I hope this can provide some confidence :)
I'd
I don’t have a ton of concern with regard to pipenv. We already just jump
through hoops to modify paths and such at runtime, this honestly sounds like a
cleaner approach. Obviously we won’t actually get to clean up the code for a
long time but you know...
My basic position is that we are just
On Wed, Feb 20, 2019, 08:13 Dan Ryan wrote:
> I don’t have a ton of concern with regard to pipenv. We already just jump
> through hoops to modify paths and such at runtime, this honestly sounds
> like a cleaner approach. Obviously we won’t actually get to clean up the
> code for a long time but
On Wed, 20 Feb 2019 at 16:28, Steve Dower wrote:
>
> To be totally clear, and maybe this needs to be in the PEP (probably in
> three more various forms to make sure everyone gets it), you can emulate
> most of the PEP today with "pip install --target __pypackages__/3.7 ..."
> and "$env:PYTHONPATH
On Wed, 20 Feb 2019 at 16:44, Steve Dower wrote:
>
> On 20Feb2019 0839, Paul Moore wrote:
> > On Wed, 20 Feb 2019 at 16:28, Steve Dower wrote:
> >>
> >> To be totally clear, and maybe this needs to be in the PEP (probably in
> >> three more various forms to make sure everyone gets it), you can
> On 20/2/2019, at 23:19, Steve Dower wrote:
>
> On 20Feb.2019 0533, Tzu-ping Chung wrote:
>> As one of the Pipenv maintainers, however, it is my personal opinion that
>> this
>> PEP would not be end up in the “yet another standard” situation, but even be
>> beneficial to Pipenv, if done
On 20Feb2019 0839, Paul Moore wrote:
On Wed, 20 Feb 2019 at 16:28, Steve Dower wrote:
To be totally clear, and maybe this needs to be in the PEP (probably in
three more various forms to make sure everyone gets it), you can emulate
most of the PEP today with "pip install --target
On 20Feb2019 0927, Nathaniel Smith wrote:
That said, I prefer the approach of pipx
(https://pypi.org/project/pipx/) for scripts anyway. It too has the
problem of not updating your PATH for you, but at least it keeps tools
separate from dependencies, as they should be.
I think this is the third
On the first point I believe I heard this via word of mouth or some kind of
media, not too sure. I didn’t have time to verify so I took it at face value —
my fault on that one
On the second point yes I am interested in reducing duplication in all cases,
it’s a big problem for us with
On Wed, Feb 20, 2019 at 5:59 AM Nathaniel Smith wrote:
> I'd caution against folks getting too worked up about PEP 582. I know it's
> been getting a lot of attention on social media recently, but, it's a draft
> that hasn't even been submitted for discussion yet.
>
To this point, is this the
19 matches
Mail list logo
