On Mon, 24 Sep 2018 at 23:03, Dan Ryan wrote:
>
> The App/Library point is partly why we haven’t jumped on this bandwagon, the
> distinction is important and keeping things separate has been done
> intentionally. Others (such as Nick or Donald) would be in a better position
> to speak to this
Pipenv wraps pip usages inside a virtual environment, so pip is always
available via “pipenv run pip”,
so in a sense Pipenv “supports” everything pip does. But as far as things
Pipenv actually has wrapper
commands for, it only tries to be pip’s functional superset in “install” and
“uninstall”; e
On Tue, Sep 25, 2018 at 1:25 AM, Tzu-ping Chung wrote:
> Pipenv wraps pip usages inside a virtual environment, so pip is always
> available via “pipenv run pip”,
> so in a sense Pipenv “supports” everything pip does. But as far as things
> Pipenv actually has wrapper
> commands for, it only tries
On Tue, 25 Sep 2018 at 19:48, Chris Jerdonek wrote:
> What I'm trying to gauge is, if the plan is for pipenv not to depend
> on pip, and pipenv has strictly greater functionality than pip, then
> what purpose will PyPA have in continuing to develop pip in addition
> to pipenv?
That's not the plan
On Tue, 25 Sep 2018 at 02:16, Daniel Holth wrote:
>
> You could probably implement this outside of setuptools as an extension.
> Clients would add a load-toml line to setup.py. Do build requirements work
> yet?
>
> One obstacle might be reconciling the all-strings nature of .cfg with typed
> to
On Tue, Sep 25, 2018 at 3:21 AM, Nick Coghlan wrote:
> On Tue, 25 Sep 2018 at 19:48, Chris Jerdonek wrote:
>> What I'm trying to gauge is, if the plan is for pipenv not to depend
>> on pip, and pipenv has strictly greater functionality than pip, then
>> what purpose will PyPA have in continuing t
On Tue, 25 Sep 2018 at 10:46, Chris Jerdonek wrote:
>
> On Tue, Sep 25, 2018 at 1:25 AM, Tzu-ping Chung wrote:
> > Pipenv wraps pip usages inside a virtual environment, so pip is always
> > available via “pipenv run pip”,
> > so in a sense Pipenv “supports” everything pip does. But as far as thin
We are using pip internals for things pip wasn’t implemented for. Specifically,
Pipenv uses pip’s package-fetching functions to implement its platform-agnostic
resolver. pip does not have this, so there’s no functional overlap here. Those
utilities are used to build something that doesn’t exist in
On Tue, Sep 25, 2018 at 3:47 AM, Tzu-ping Chung wrote:
> We are using pip internals for things pip wasn’t implemented for.
> Specifically,
> Pipenv uses pip’s package-fetching functions to implement its
> platform-agnostic
> resolver. pip does not have this, so there’s no functional overlap here
On Tue, 25 Sep 2018 at 12:53, Chris Jerdonek wrote:
>
> On Tue, Sep 25, 2018 at 3:47 AM, Tzu-ping Chung wrote:
> > We are using pip internals for things pip wasn’t implemented for.
> > Specifically,
> > Pipenv uses pip’s package-fetching functions to implement its
> > platform-agnostic
> > reso
Quick note to thank Ian Stapleton Cordasco and Thea Flowers for their work
maintaining Twine! I realized I don't have time to help maintain it right now
so I'm stepping away from that, and am grateful for their work, including new
releases this month: https://pypi.org/project/twine/#history
And
FYI pipenv have been vendoring pip since pretty early in the projects
existence, since before 10 was released. At no point was I in touch to say that
was a major issue though because we use the api precisely as you describe, *at
our own risk*. Every time I’ve been in touch it’s been to ask how t
On Tue, Sep 25, 2018, at 9:13 AM, Paul Moore wrote:
> I personally don't see much advantage in the "dump everything in one
> file" philosophy. so from a personal POV I'd prefer setuptools' config
> to remain in setup.cfg, but if they have reasons for wanting to move,
> the PEP allows them that opti
Yes! bdist_wheel is supposed to be how you install packages built with
setuptools on platforms without setuptools, to give you time to write its
replacement.
On Tue, Sep 25, 2018, 15:39 Thomas Kluyver wrote:
> On Tue, Sep 25, 2018, at 9:13 AM, Paul Moore wrote:
> > I personally don't see much ad
On Tue, Sep 25, 2018 at 6:46 AM, Dan Ryan wrote:
> As far as the pipenv roadmap, we are rewriting a good chunk of it but it
> essentially the atomic things we do or would like to do with regards to
> shared functionality at a high level:
>
> - parse user input/requirements
> - retrieve package m
On Tue, 25 Sep 2018 at 22:09, Dan Ryan wrote:
> To Chris’ broader point it is definitely duplicated effort and I am in full
> agreement which is why I want to establish which code should be extracted and
> generalized and where it should be maintained. But as Paul mentioned there
> also is no
On Tue, Sep 25, 2018 at 6:30 PM, Dan Ryan wrote:
> Thanks Chris, these are excellent suggestions. Can you provide a reference to
> a PR you’re working or have worked on so we can jumpstart the process on our
> end?
Hi Dan,
The PR's I've been submitting and working on aren't *primarily* of the
17 matches
Mail list logo
