Sorry for causing you additional frustration. I was also frustrated and underscoring a sense that seems to come through in most of our interactions for a number of reasons. It isn’t my intention to cause you additional grief, so I apologize for fanning the flames.
Dan Ryan // pipenv maintainer gh: @techalchemy > On Oct 1, 2018, at 4:50 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > > 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/V7IUPZ22W5YQ5HURN56I2PSFFLXWSN2P/
