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

Specify gpg --output option explicitly #1614

Closed
wants to merge 1 commit into from
Closed

Conversation

marmarek
Copy link

@marmarek marmarek commented Dec 29, 2018

Do not rely on obscure default behavior of gpg, which may not work with alternative implementations (like qubes-gpg-client-wrapper).

Summary of changes

Make it work with gpg that does not have default output file. See QubesOS/qubes-issues#4612 for example.

Pull Request Checklist

  • Changes have tests
  • News fragment added in changelog.d. See documentation for details

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Do not rely on obscure default behavior of gpg, which may not work with alternative implementations (like qubes-gpg-client-wrapper).
@pganssle
Copy link
Member

@marmarek I guess this is just making the default behavior we're relying on explicit?

One thing to note is that setup.py upload is very much deprecated in favor of twine. This functionality will simply raise an exception soon.

I'm on the fence about this because I don't think it hurts anything and the work is already done, but on the other hand this is not functionality that we currently support and anyone using it should stop doing so.

If we decide to accept this contribution, it will need a news fragment.

@ThomasWaldmann
Copy link

I just tried to fix this on the qubes side, before seeing this PR.
There was no easy solution to do that, so fixing this on the setuptools side would be way easier.

If setuptools relies on getting the signature in <filename>.asc, it should be no problem explicitly saying so via --output ....

@jaraco
Copy link
Member

jaraco commented Jan 27, 2019

I'm leaning more toward not accepting this change and to simply encourage migration to twine, unless a compelling use-case can be shown that shows that setup.py upload satisfies but twine doesn't.

@jaraco
Copy link
Member

jaraco commented Apr 5, 2019

Thanks again for the contribution, but we really do recommend instead to use twine.

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

Successfully merging this pull request may close these issues.

None yet

4 participants