Hi, I'm sorry, but I'm not going to respond to this message. For some time now I've been considering taking a break from open source mailing lists, as I'm finding that the frustration involved in dealing with some of the more confrontational threads (until now, mostly on other lists than this one) has been affecting my personal life. So as of now, I'm on a break for the period of October.
One final thing I will say is that I find comments like "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" and "you personally have taken an active position of trying to make us leave you alone" is a startling and pretty aggressive misinterpretation of what I was trying to say. I'm going to assume your comments were in good faith, and that I simply didn't explain myself well enough, or you misunderstood what I was saying, but I will say that whatever the reason, these comments were fairly key in convincing me that I don't have to take this sort of thing in what's supposed to be a fun hobby activity. I hope the discussion goes well, and I'll check back in in November to see where it has led. Paul On Sun, 30 Sep 2018 at 21:43, 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/3EREWQ4ZNDBMAAONSUZQ2URAEFYLENKD/
