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 <d...@danryan.co> wrote: > > 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 about the distinction between > application and library usage which actually _IS_ central to the entire > conversation, and barely mentioned pipenv at all in his discussion about the > tradeoffs between various approaches to specifying dependencies as a user. > > Since pipenv actually has implemented one of these approaches which > specifically targets the distinction, effectively drawing a line between > libraries and applications, it is particularly relevant as a point of > discussion in the conversation about "new user experience" in the ecosystem > of people who are sitting down for the first time and trying to set up a > virtual environment, install dependencies, install python, etc. If you keep > rushing to tell us to go away and talk about things off list rather than > trying to understand the relevance of what we're trying to talk about, we > will never have a productive conversation. > > I get that your attention is split, mine is too. But we are going to have to > talk about specific tools in order to evaluate the tradeoffs they make and > you may need to accept that even though you personally have taken an active > position of trying to make us leave you alone, many people use pipenv in the > python community and it may actually be a good starting point for discussing > this kind of a problem. > > Given that we are talking 'one tool vs many tools' it seems like a good idea > to look at how other languages handle these problems, including (and probably > starting with) what is possibly the core decision that would need to be made > before you could even start standardizing -- do you want libraries and > applications managed by the same workflow, or not. Is that not a > conversation that we want to have? If not, what conversation topics are we > allowed to address in this discussion? > > > Dan Ryan > gh: @techalchemy // e: d...@danryan.co > > > > -----Original Message----- > > From: Paul Moore [mailto:p.f.mo...@gmail.com] > > Sent: Sunday, September 30, 2018 3:57 PM > > To: Tzu-ping Chung > > Cc: Distutils > > Subject: [Distutils] Re: Notes from python core sprint on workflow tooling > > > > On Sun, 30 Sep 2018 at 20:50, Tzu-ping Chung <uranu...@gmail.com> wrote: > > > > > > > > > > On 01/10, 2018, at 00:47, Dan Ryan <d...@danryan.co> 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 intended to replace requirements.txt per some > > previous thread on the topic, and pipenv was an experimental > > implementation of the separation between the two different ways that > > people currently use requirements.txt in the wild -- one as a kind of > > abstract, > > unpinned dependency list (Pipfile), and the other as a transitive closure > > (Pipfile.lock). Since neither is standardized _for applications_, I'm not > > totally > > sure this is an actual sticking point. > > > > > > > > In either case, this seems super minor… > > > > > > I feel this would need to be extensively discussed either way before the > > community can > > > jump into a decision. The discussion I’ve seen has been quite split on > > whether we should > > > use one file or the other, but nothing very explaining why outside of “one > > file is better > > > than two”. > > > > This discussion seems to have diverted into being about pipenv. Can I > > ask that the pipenv-specific discussions be split out into a different > > thread? (For example, I'm not clear if Tzu-Ping's comment here is > > specific to pipenv or not). > > > > My main reason is that (as I noted in my reply to Nathaniel's post) my > > use cases are, as far as I can tell, *not* suitable for pipenv as it's > > currently targeted (I'm willing to be informed otherwise, but please, > > can we do it on another thread or off-list if it's not generally > > useful). And I'd rather that we kept the central discussion > > tool-agnostic until we come to some view on what tools we'd expect to > > be suggesting to users in the various categories we end up > > identifying. > > > > Thanks, > > Paul > > -- > > Distutils-SIG mailing list -- distutils-sig@python.org > > To unsubscribe send an email to distutils-sig-le...@python.org > > https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ > > Message archived at https://mail.python.org/mm3/archives/list/distutils- > > s...@python.org/message/ZMWZ4FDME7W5LK2T2DCBAIJFP7L3TSMW/ > -- > Distutils-SIG mailing list -- distutils-sig@python.org > To unsubscribe send an email to distutils-sig-le...@python.org > https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ > Message archived at > https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/UM5GTRUUXPBDXH4KMQQONXVLMHYEE7GF/ -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/ZIPNF5NNGFNDTIWRHRR5DDUUJHTJCEQO/
