Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Read data from the packages? #7

Open
phildini opened this issue Feb 11, 2018 · 10 comments
Open

Read data from the packages? #7

phildini opened this issue Feb 11, 2018 · 10 comments
Assignees

Comments

@phildini
Copy link
Owner

phildini commented Feb 11, 2018

A suggestion from @EricaJoy was to figure out some way of reading this info from the packages themselves, rather than a central database.

(Relates to feross/thanks#2)

Today, few-to-no package authors are capturing this metadata in their packages. Two approaches that come to mind:

  1. Make it possible for that info to go in the setup.py
    • Ideally this would also be fetchable via PyPI API.
  2. Encourage maintainers to ship a .thanks.json in their packages, and check from the package to read from there.

Edit: I have filed pypa/setuptools#1276 to try and get the ball rolling on this.

@kootenpv
Copy link

kootenpv commented Feb 11, 2018

It somehow seems like a bad idea to have this centralized.

How about someone evil sending a payment request to all people mentioned in this single thanks.json file?

@phildini
Copy link
Owner Author

So, let's be clear: Today, this needs to be centralized. It's going to be centralized until there's another way. Anyone who wants their info removed, I will respect - so far all of these have been volunteered or are on the public web.

This thread is for discussion about how to get to decentralization.

@kootenpv
Copy link

I understand, I just came to raise an issue and it already fit in this thread.

I would vote for an extended CONTRIBUTORS file including payments info.

@untitaker
Copy link
Contributor

If you are keeping a central database, you have to ensure that the PRs adding to that DB are not potentially malicious (i.e. somebody trying to funnel donations of a larger project to their own accounts). I don't think this moderation effort scales even in the mid term.

Both the scaling and the security problems go away if you tell packagers to add metadata to their own packages. They have plenty of incentive to do so.

@phildini
Copy link
Owner Author

@untitaker I agree, and I am in the process of filing issues with the relevant repos to make this easier for all.

If you have suggestions of the right place to store it, I'm all ears.

@kootenpv
Copy link

kootenpv commented Feb 13, 2018 via email

@phildini
Copy link
Owner Author

Update on where I'm thinking of heading. The spec for metadata behind setup.py already defines the capability for a project_urls dict to be an argument to setup.py. I'm thinking of encouraging maintainers to add a Funding url or something of the like. You can look at https://github.com/phildini/thanks/commit/a4e549338eb3e3c70b1dd5628b38dcbdbf63443a as an example.

@untitaker
Copy link
Contributor

@kootenpv there is no standardized format for CONTRIBUTORS. I also wasn't under the impression that thanks was about supporting every contributor, but rather the (core) maintenance.

@phildini Apart from a field people have to add, what about scraping the README/long_description for patreon/flattr/paypal/...-links or simply links with "donation"/"donate" in them?

@phildini
Copy link
Owner Author

I'd rather not assume from data parsing if I can avoid it. Scraping a text file is not my ideal here, because if I guess wrong it's a crappy experience.

As for supporting all contributors vs. supporting the project: Ideally I'd like to allow for both. The link in setup.py is a step towards getting the project supported, but both would be great.

@phildini
Copy link
Owner Author

Starting point:

[line for line in pkg_resources.get_distribution('thanks').get_metadata_lines(pkg_resources.get_distribution('thanks').PKG_INFO) if line.startswith('Project-URL:')]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants