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?
an.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
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
re [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 wrote:
> >
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 work
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
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
> 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 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
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, 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 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 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, 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, 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
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
>
17 matches
Mail list logo
