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

Upload to PyPI #11

Closed
Julian opened this issue Nov 11, 2019 · 4 comments
Closed

Upload to PyPI #11

Julian opened this issue Nov 11, 2019 · 4 comments

Comments

@Julian
Copy link
Contributor

Julian commented Nov 11, 2019

Hi. Would you consider uploading this to PyPI?

Thanks.

@newren
Copy link
Owner

newren commented Nov 12, 2019

I don't know what this entails. I started poking around and found https://packaging.python.org/tutorials/packaging-projects/, which didn't show how to work with just a single file. https://stackoverflow.com/questions/12461603/setting-up-setup-py-for-packaging-of-a-single-py-file-and-a-single-data-file-wi suggests you must restructure the project to make a subdirectory, which is ridiculous and made me almost quit and just say no way. http://www.agapow.net/programming/python/setuptools-and-the-single-file/ suggests there is a way around it and provides some pointers, but also notes that "The non-functional rst2beamer sat on PyPi for months before someone informed me it wasn't working", which is rather worrisome. Do I want to go through the pain of figuring out PyPI uploading just to have a similar fate?

Also, how does PyPI handle different installations having the python3 executable named "python3" in some places and "python" in others? That seems to be causing problems, and I'm worried uploading to PyPI is going to reinforce or extend them.

I'm not in principle against uploading to PyPI, but someone would need to do a little legwork. If it's me, it might be a while.

@Julian
Copy link
Contributor Author

Julian commented Nov 12, 2019

Nah you don't need to restructure the project. I'm happy to send a PR adding the setup.py/cfg.

I won't throw any shade on anyone who didn't find it given Python's history of subpar packaging documentation (which overall is getting better), but the solution for single files is the pymodules argument, which yeah like I said happy to send in a PR.

Also, how does PyPI handle different installations having the python3 executable named "python3" in some places and "python" in others? That seems to be causing problems, and I'm worried uploading to PyPI is going to reinforce or extend them.

In general you should assume python always means Python 2, and python3 always means Python 3 (which is the python-dev recommendation. Arch is weird essentially, and one of only 2 places really that the above doesn't hold true, but that also means Arch is familiar with how to unbreak itself for everyone following the upstream recommendation). If the script's written for Py3, it should have /usr/bin/env python3 as its shebang, but it doesn't matter much, since pip, which is how you install things from PyPI, will transparently rewrite that shebang if needed when it installs the package (and will point it at the right Python).

PR incoming whenever I get some spare moments...

@newren
Copy link
Owner

newren commented Nov 13, 2019

Yeah, I'm aware of the python2 vs. python3 recommendation that was made in the past, but I'm also aware that there were movements afoot to change it (see https://lwn.net/Articles/780737/). Also, it's not just Arch: Windows users apparently have a python3 named "python" (see issue #4 and PR #10 ). Good to know that pip handles the shebang line as needed, though.

Looking forward to your contributions!

@newren
Copy link
Owner

newren commented Dec 26, 2019

2.23.0 and 2.24.0 have been uploaded to PyPI. I tried to check that I did everything already, but if something is amiss, let me know.

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

Successfully merging a pull request may close this issue.

2 participants