Add setup.py script to build the package using setuptools #143
Conversation
|
Thanks so much for the PR. I'm obviously no expert in setuptools (otherwise I'd have set this up myself) but it basically looks plausible to me. But I think a couple of things are needed before this can be merged:
|
|
Thanks for the feedback. I'm happy to work through this and then I'll post a message here when complete.
Should I plan instructions to install the via PyPI? IMO, that would be most convenient to end users. If you're unfamiliar with the steps to upload to PyPI, I can help you through them. |
|
I've updated the PR with the following changes:
Thanks! Let me know if you have any additional feedback. |
There was a problem hiding this comment.
That's awesome, @jdufresne! I left a little comment about some duplicated code, but otherwise it looks good to me (to the extent that I can judge).
Should I plan instructions to install the via PyPI? IMO, that would be most convenient to end users. If you're unfamiliar with the steps to upload to PyPI, I can help you through them.
I actually have a PyPI account ("mhagger") and have uploaded other projects there before…like ten years ago 😕 So if you could give me a two-sentence reminder or a pointer to instructions, that would be helpful. I assume that git-imerge would be a suitable project name? (It's not yet claimed.)
Also, I suppose that I should release a version 1.2.0 while I'm at it, so that the release agrees with the packaging changes that you are making.
| if __name__ == '__main__': | ||
| try: | ||
| main(sys.argv[1:]) | ||
| except Failure as e: | ||
| sys.exit(str(e)) | ||
|
|
||
|
|
||
| if __name__ == "__main__": |
There was a problem hiding this comment.
This block and the if __name__ == '__main__': block just above it seem to be redundant. And this one doesn't appear to pass the command-line arguments into main().
| include t/create-test-repo | ||
| include t/test-conflicted | ||
| include t/test-drop | ||
| include t/test-unconflicted |
There was a problem hiding this comment.
Just to be clear...the files under t/ are only needed for testing. Their inclusion here doesn't imply that they will be installed for end-users, does it?
There was a problem hiding this comment.
Correct.
It is customary to include test files in an sdist (source distribution).
- Many Linux distro packagers require tests and for them to pass when adding a new package to their repository.
- It allows end users to sanity check the state of the released package.
While these files are included in the .tar.gz file, they are not installed on the user's system.
|
Oh, another thing: it looks like |
Sure thing. I think git-imerge would be a great name! Once you've finalized all changes to the release, you normally do something like: The first command builds the sdist file (source distribution). The second one uploads it. It will prompt you for a username and password. If you don't have twine installed, you can install it using If you're using Linux, it may also be available through your distro repository. You can also execute twine with the command: The following guide is an excellent source for more details: |
|
Changes:
|
gitimerge.py
Outdated
| try: | ||
| main(sys.argv[1:]) | ||
| main() |
There was a problem hiding this comment.
It took me a while to figure out how the command-line arguments are getting through to main. (I wondered about that here.) It used to be that they were passed to main here. But now, nothing is passed to main, and nothing anywhere in the script references sys.argv anymore.
It turns out that we are relying on this call to parser.parse_args(), which now passes None to that method, which triggers argparse's default behavior of taking the arguments directly from sys.argv.
This seems a bit magical to me. Is there a reason not to continue passing sys.argv[1:] explicitly here, as was done before? ("This is the standard pattern now" would an acceptable answer.) Otherwise, could main get a short docstring explaining that args = None implies that the arguments will be taken from sys.argv?
Otherwise, everything looks great! Thanks for your patience 😃
Setuptools is a fully-featured, actively-maintained, and stable library designed to facilitate packaging Python projects. It is the standard library used to create Python packages by the community. The setup.py script allows building an sdist package and a wheel package. Installing the package with setuptools installs a gitimerge.py module and a git-imerge command line script. A tox configuration was added to automate testing in a virtualenv. The README has been updated with new installation and testing instructions.
|
I have restored the user of I'm ok either way. I only removed it because it feels rather typical to me across |
|
I just pushed a couple more commits to a branch "setuptools" under |
|
Yup, those all look good to me. Thanks! |
|
The ability to run There are also new attempts to package Python code without |
@mhagger any updates? |
|
I don't know why I never merged this. Sorry. |
Setuptools is a fully-featured, actively-maintained, and stable library
designed to facilitate packaging Python projects. It is the standard
library used to create Python packages by the community.
The setup.py script allows building an sdist package and a wheel
package. Installing the package with setuptools installs a gitimerge.py
module and a git-imerge command line script.
As this package is pure Python and compatible with both Python 2 & 3,
the wheel is marked as universal.
This continues the work started in PR #55. If work in that PR continues, I'm happy to close this one.