[Distutils] Re: Notes from python core sprint on workflow tooling

[Nicholas Chammas]

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 understand if he was
> reluctant to do so
> even if I did. The mailing list could be a bit intimidating unless you
> have a good topic to
> join, especially for someone not with an English-speaking background (I am
> talking from
> experience here).
>
> Overall I could see it be a good idea to invite him to join the mailing
> list, and/or provide
> inputs on this particular discussion. Would you be interested in doing
> this?
>

Sure, I'll ping him and point to this thread and see if he is interested in
participating.

Nick
--
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/XX65JLHDFESUETCSA5HCTOHZ2RWJDGVS/

[Distutils] Re: Notes from python core sprint on workflow tooling

[Nicholas Chammas]

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 sprint a few weeks ago, I dragged some
> interested parties [4] into a room with a whiteboard [5], and we made
> a start at it. And now I'm writing it up to share with you all.
>

Just curious: Have we directly engaged the author of Poetry
 to see if he is interested in
participating in these discussions?

I ask partly just as an interested observer, partly because I see that
Pipenv tends to dominate these discussions, and partly because I find
Poetry more appealing than Pipenv
 and -- not being a
packaging expert -- I want to see it discussed in more depth by the experts
here.

Nick
--
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/NKFEQ3G2N5F745NZ6VNJIAJRXOWNYT5T/

[Distutils] Re: Make an ordered list of sdists to be installed?

[Nicholas Chammas]

I don’t know the details, but I did read that Poetry has a sophisticated
dependency resolver.

https://github.com/sdispater/poetry

I don’t know if there is a way to access the resolver independently of the
tool, but perhaps it would provide a handy reference.
2018년 7월 23일 (월) 오전 5:49, Thomas Kluyver 님이 작성:

> Hi all,
>
> Do we know of any tool that can, given the name of one or more packages,
> follow dependency chains and produce a list of packages in the order they
> need to be installed, assuming every package needed will be built from
> source?
>
> Running "pip download --no-binary :all: ipython" gets me a set of sdists
> to be installed, but I lose any information about the order. I assume some
> packages will fail to build if their dependencies are not installed first,
> so the order is significant.
>
> Pip appears to keep track of the ordering internally: if I run "pip
> install --no-binary :all: ipython", all the dependencies are downloaded,
> and then the collected packages are installed starting from those with no
> dependencies and finishing with the package I requested. But I don't know
> of any way to get this information out of pip. Is there an option that I'm
> overlooking? Or some other tool that can do this?
>
> The use case I'm thinking about is to automatically generate instructions
> for a build system which separates the downloading and installing steps, so
> for each step it expects one or more URLs to download, along with
> instructions for how to install that piece. The installation steps
> shouldn't download further data. I could work around the issue by telling
> it to download all the sdists in a single step and then install in one shot
> with --no-index and --find-links. But it's more elegant - and better for
> caching - if we can install each package as a single step.
>
> Thanks,
> Thomas
> --
> 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/LGTH3IYBMVKBS4PYGFJ6A7N5GW5ZKFUY/
>
--
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/BSODWBIYPSOGHUWJRPZ4Y2SZSSU4ZDGG/

Re: [Distutils] Contributing money to package authors/maintainers via PyPI

[Nicholas Chammas]

On Sat, Jul 23, 2016 at 3:11 PM Donald Stufft don...@stufft.io
<http://mailto:don...@stufft.io> wrote:


> On Jul 23, 2016, at 2:40 PM, Nicholas Chammas <nicholas.cham...@gmail.com>
> wrote:
>
> I know a more concrete proposal would have to address a lot of details
> (e.g. like how to split contributions across multiple maintainers), and
> perhaps there is no way to find the resources to build or maintain such a
> thing in the first place. But just for now I’d like to separate essence of
> idea from the practical concerns of implementing it.
>
>
>
> I’m mulling over the idea in my head, but one other thing we’d need to
> figure out is the *legality* of doing this and if it’s something the PSF is
> willing to do at all.
>
Would it simplify things for the PSF if they partnered with someone who
took care of moving the money around?

The PSF, via PyPI, would bring a large, opt-in user base to their doorstep,
and in return the payment provider (e.g. Gratipay, Salt) would cut the PSF
some tiny slice of each transaction.

I don’t know if this tweak makes the proposal more realistic (again, maybe
the margins wouldn’t work for the provider), but at least on first blush I
think would help us accomplish the following:

   - We offer the community a low-friction, standardized way to support
   projects they care about.
   - The PSF doesn’t have to handle thorny legal and accounting issues, at
   least not as bad as they would if they handled the payments directly.
   - The PSF builds up a funding stream that can support our core
   infrastructure.

Nick
​
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Contributing money to package authors/maintainers via PyPI

[Nicholas Chammas]

On Sat, Jul 23, 2016 at 3:35 PM Daniel Holth  wrote:

> Have you seen https://rubytogether.org ? It looks like exactly what you
> are proposing, only with more blocks.
>

Interesting. I hadn't heard of that before now.

I'm not sure what you mean by "with more blocks", but that idea seems
focused on funding core Ruby infrastructure, whereas I'm proposing a way
for users to fund any Python project they want, with the added benefit that
by funding those projects they automatically also fund core Python
infrastructure too.

A rough -- but in my view very apt -- analogy for what I'm proposing would
be the iOS App Store. Users buy apps they want; when that happens, the app
developers benefit by getting paid for their work, and the general iOS
ecosystem also benefits since the maintainer of that ecosystem, Apple, gets
a cut of those payments.

Of course, in our case we are talking about voluntary monetary
contributions and not prices, and we are talking about tiny fees and not
15-30% cuts. But the basic idea is the same: Fund the core infrastructure
by capturing some of the value generated by that infrastructure.

The core infrastructure would be things like PyPI, tooling like pip, and
Python itself. The value generated by that infrastructure, for the purposes
of this discussion, would be the monetary contributions people made to
projects they appreciated. And capturing some of that value would be taking
a tiny cut out of those contributions and reinvesting it in the core.

Nick
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Contributing money to package authors/maintainers via PyPI

[Nicholas Chammas]

On Sat, Jul 23, 2016 at 3:22 PM Nathaniel Smith <n...@pobox.com> wrote:

> On Jul 23, 2016 11:40 AM, "Nicholas Chammas" <nicholas.cham...@gmail.com>
> wrote:
> >
> [...]
>
>
> > You can already do this today, of course, with services like PayPal,
> Gratipay, and Salt. But the process is scattered and different for each
> Python package and the group of people behind it. What’s more, it seems
> wrong that these third-party services should capture some of the value
> generated by the Python community (e.g. by charging some transaction fee)
> without any of it going back to support that community (e.g. via the PSF).
>
> These kinds of money transfer services are pretty competitive, and AFAIK
> their transaction fees are largely set by companies like VISA, plus the
> actual costs of running this kind of business. (And this is much more than
> just shuffling bits around - there are all kinds of complicated regulations
> you have to comply with around issues like "how do you know that organized
> crime isn't using your service for money laundering". IIRC every country
> and US state has their own idea about what counts as adequate safeguards.)
> I think it's vanishingly unlikely that the PSF could provide these services
> more efficiently than these dedicated companies. So I don't think the PSF
> is going to get rich on transaction fees.
>

Agreed that it doesn't make sense for us to reinvent this wheel, at least
not unless the idea is massively successful.

I was thinking the PSF could perhaps start off by partnering with one of
these organizations who have already figured this stuff out. The PSF/PyPI
would bring a whole new group of users to their service, and in return the
service provider (e.g. Salt) would give the PSF some cut of their fee.

Not sure if that's viable (maybe the margins are too low?), but that's what
I was thinking.

Nick
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] Contributing money to package authors/maintainers via PyPI

[Nicholas Chammas]

This may be a heretical idea, and it’s definitely not something anyone is
likely to take on anytime soon, but I’d like to put it up for discussion
and see what people think.

I often find myself wanting to show gratitude to the authors or maintainers
of a package by giving money. Most of the time, it is easier for me to give
money than time. After all, contributing time in a meaningful way to a
project can be quite difficult. I wonder how many others find themselves in
a similar situation, wanting to chip a few bucks in as a token of gratitude
for someone’s work, either one-time or on an ongoing basis.

You can already do this today, of course, with services like PayPal,
Gratipay , and Salt .
But the process is scattered and different for each Python package and the
group of people behind it. What’s more, it seems wrong that these
third-party services should capture some of the value generated by the
Python community (e.g. by charging some transaction fee) without any of it
going back to support that community (e.g. via the PSF).

So that raises the question: How about if people could contribute money to
the people behind projects they felt grateful for via PyPI? PyPI is already
the community’s central package hub. Perhaps it could also be the
community’s central hub for contributing money.

The central goal would be to create a low-friction ecosystem of monetary
contributions that benefits Python package authors/maintainers, as well as
the larger Python ecosystem. At a high-level, the ecosystem would be
opt-in, and contributions would go directly to their intended recipients,
with tiny cuts of each transaction going to the payment processor and some
Python community organization like the PSF.

I know a more concrete proposal would have to address a lot of details
(e.g. like how to split contributions across multiple maintainers), and
perhaps there is no way to find the resources to build or maintain such a
thing in the first place. But just for now I’d like to separate essence of
idea from the practical concerns of implementing it.

Assume the work is already done, and we have such a system of monetary
contributions in place today. My questions are:

   - Would such a system benefit the Python community?
   - Would the cut of transactions that went to the PSF (or similar) be
   enough to cover the cost of maintaining the system and meaningfully impact
   other Python efforts?
   - Would such a system create perverse incentives?
   - Would it just be a dud that very few people would use?

I’m trying to get a feel for whether the idea has any potential.

Nick
​
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] comparison of configuration languages

[Nicholas Chammas]

On Tue, May 10, 2016 at 11:15 AM Donald Stufft don...@stufft.io
 wrote:


> > On May 10, 2016, at 11:00 AM, Antoine Pitrou 
> wrote:
> >
> > (as an aside, if there's the question of forking an existing parser
> > implementation for better vendorability, forking a YAML parser may be
> > more useful to third-party folks than forking a TOML parser :-))
>
>
> I’m seeing what I can come up with (https://github.com/dstufft/yaml)
> though
> I don’t know that I feel like actually maintaining whatever it is I end up
> figuring out there.
>
Did you intend to fork from https://github.com/yaml/pyyaml? I believe the
latest PyYAML is actually hosted on BitBucket:

https://bitbucket.org/xi/pyyaml/

Also, a better starting point than PyYAML may be this existing fork of the
library, ruamel.yaml:

https://bitbucket.org/ruamel/yaml

The fork makes several 
changes

which may be relevant to you.

Nick
​
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] comparison of configuration languages

[Nicholas Chammas]

On Sat, May 7, 2016 at 6:23 AM Paul Moore p.f.mo...@gmail.com
 wrote:

- YAML ought to be wonderful, but it ended up over-engineered (yes, we
> can ignore the bits we don't care about). Also, pyYAML is a bit of an
> annoying dependency (big, reportedly slow unless you use the C
> version) - not something I'd want pip to have to vendor.
>
Perhaps a more limited YAML library like Poyo would address some of the
concerns we have about using PyYAML.

https://github.com/hackebrot/poyo#readme

Poyo in particular may be *too* limited, but I wonder how much it would
sway people if we used YAML but not PyYAML.

Anyway, here are some relevant snippets from Poyo’s README:

Please note that Poyo supports only a chosen subset of the YAML format.
It can only read but not write and is not compatible with JSON.
…
Poyo is 100% Python and does not require any additional libs.

Nick
​
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] How to deprecate a python package

[Nicholas Chammas]

FYI, there is an existing issue on Warehouse's tracker for this:
https://github.com/pypa/warehouse/issues/345
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] Thank you for the ability to do `pip install git+https://...`

[Nicholas Chammas]

Dunno how old/new this feature is, or what people did before it existed,
but I just wanted to thank the people who thought of and built the ability
to do installs from git+https.

It lets me offer the following to my users when they want the “bleeding
edge”  version
of my project:

pip install git+https://github.com/nchammas/flintrock

I also use this capability to install and test contributors’ branches when
they open PRs against my project. For example:

pip install git+https://github.com/contributor/flintrock@branch

It’s a great feature and makes my work a bit easier. Thank you for building
it.

I’m still waiting for when I can give the PyPA some money
 for all the good and sorely
needed work that y’all do…

Anyway, keep it up.

Nick
​
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig