[Splitting off a new thread for this question even if it might not
result in a discussion]
On Sun, Sep 30, 2018 at 10:00 AM Dan Ryan wrote:
>
> Anyway, this is all a good discussion to have and I really appreciate you
> kicking it off. I've been following the __pypackages__ conversation a bit
On Sun, 30 Sep 2018 at 20:50, Tzu-ping Chung wrote:
>
>
> > On 01/10, 2018, at 00:47, Dan Ryan wrote:
> >
> >> Uses Pipfile as a project marker instead of pyproject.toml.
> >
> > See above. pyproject.toml wasn't standardized yet when pipenv was released
> > (and still isn't, beyond that it is
Pipfile is not pipenv, and the original thread specifically discussed the
pipenv implementation of the identified needs -- since pipenv is in wide use,
even if you personally don't like or use it, it seemed helpful to discuss the
limitations.
Tzu-ping went ahead and expanded the discussion
On Sun, Sep 30, 2018 at 2:25 PM, Chris Jerdonek
wrote:
> [Splitting off a new thread for this question even if it might not
> result in a discussion]
>
> On Sun, Sep 30, 2018 at 10:00 AM Dan Ryan wrote:
>>
>> Anyway, this is all a good discussion to have and I really appreciate you
>> kicking
In reading this discussion, I feel like a cool picture would be a Venn
diagram of several of the common tools out there, with dots (or some
other type of regions) to represent the various use cases they do or
don't support.
--Chris
On Sun, Sep 30, 2018 at 1:46 PM Dan Ryan wrote:
>
> Pipfile is
I read and mostly agree with Chris and Paul as we operate in similar spaces and
probably have similar experiences with trying to unify packaging related
tooling (its hard, we are all currently trying to undo this).
Without getting too focused on the details, despite the technical and
On Sun, Sep 30, 2018, at 2:35 PM, Paul Moore wrote:
> Personally, I think that the toolkit approach (standards, interop, low
> level support) is where distutils-sig and PyPA works best. Higher
> level unifications ("one tool to rule them all") have historically
> been much less successful.
I
On Sun, Sep 30, 2018 at 6:48 AM Nathaniel Smith wrote:
> So I think now might be a time for a bit of top-down design. **I want
> a picture of the elephant.** If we had that, maybe we could see how
> all these different ideas could be put together into a coherent whole.
> So at the Python core
On Sun, Sep 30, 2018 at 2:17 PM Tzu-ping Chung wrote:
> I can’t speak for others (also not really sure what “we” should include
> here…), but I
> have a couple of interactions with the author on Twitter. I can’t recall
> whether I invited
> him to join distutils-sig specifically, but I would
> On 01/10, 2018, at 00:47, Dan Ryan wrote:
>
>> Uses Pipfile as a project marker instead of pyproject.toml.
>
> See above. pyproject.toml wasn't standardized yet when pipenv was released
> (and still isn't, beyond that it is a file that could exist and store
> information). Pipfile was
> On 01/10, 2018, at 00:47, Dan Ryan wrote:
>
>> Can't install Python. (There's... really no reason we *couldn't* distribute
>> pre-built Python interpreters on PyPI? between the python.org installers and
>> the manylinux image, we're already building redistributable run-anywhere
>> binaries
I didn’t intend my comments to be specific to Pipenv, but it is about Pipfile
being
considered why Pipenv is not suitable.
Whether different kinds of projects should share one configuration file is an
important but less addressed design decision, and the decision is not yet made.
Considering
I can’t speak for others (also not really sure what “we” should include here…),
but I
have a couple of interactions with the author on Twitter. I can’t recall
whether I invited
him to join distutils-sig specifically, but I would understand if he was
reluctant to do so
even if I did. The mailing
On Sun, 30 Sep 2018 at 22:17, Chris Jerdonek wrote:
>
> In reading this discussion, I feel like a cool picture would be a Venn
> diagram of several of the common tools out there, with dots (or some
> other type of regions) to represent the various use cases they do or
> don't support.
Yeah, that
On Sun, 30 Sep 2018 at 13:26, Chris Jerdonek wrote:
> It can be challenging to get stuff like
> this working if the tools you're using make too many directory or
> workflow assumptions. However, a very powerful or flexible tool (e.g.
> Git), or a collection of several tools that each does one
On Sun, 30 Sep 2018 at 11:48, Nathaniel Smith wrote:
>
> Now that the basic wheels/pip/PyPI infrastructure is mostly
> functional, there's been a lot of interest in improving higher-level
> project workflow.
[...]
> This is very much a draft, intended as a seed for discussion, not a
>
On Sun, Sep 30, 2018 at 4:30 AM Paul Moore wrote:
>
> On Sun, 30 Sep 2018 at 11:48, Nathaniel Smith wrote:
> >
> > Now that the basic wheels/pip/PyPI infrastructure is mostly
> > functional, there's been a lot of interest in improving higher-level
> > project workflow.
> [...]
> > This is very
Now that the basic wheels/pip/PyPI infrastructure is mostly
functional, there's been a lot of interest in improving higher-level
project workflow. We have a lot of powerful tools for this –
virtualenv, pyenv, conda, tox, pipenv, poetry, ... – and more in
development, like PEP 582 [1], which adds a
18 matches
Mail list logo
