-
Notifications
You must be signed in to change notification settings - Fork 71
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
Flit packaging #29
Flit packaging #29
Conversation
Fine with me, go ahead. |
OK, going with option 1 (wheels only) for now. We can consider option 2 or 3 later if there are too many complaints. |
|
I avoid using setuptools if I possibly can, because it has messed up my import path order so often. I detest that package. |
After some experience accommodating the use of Just expressing this is maintenance cost, and I'm not sure what the win is. |
Sorry, I didn't realise you were testing against development versions of ptyprocess in that script as well. I think it's simplest for ptyprocess to revert this for now. I'll open a PR to do that. For the record, there are various things I like about using flit, like reducing the duplication of the version number without ugly hacks, eliminating the need for package_data and MANIFEST.in, and the ability to easily refer to a separate file for the long description. It's a collection of small wins rather than one big one - although for me, not being setuptools is a huge win all by itself. |
@jquast flit is my packaging tool to build wheels without involving setuptools. With this branch I can build a wheel by running
flit wheel
.We can use this:
setup.py
andMANIFEST.in
. This means that future releases would only have wheels on PyPI, not sdist tarballs. I'm already doing this for a number of my other projects - pip has been able to install wheels for about 2½ years - but it may surprise some people.__version__
, which we need to update anyway.