[WIP] Setuptools packaging improvements - make each st2 component packagable and installable via package #1677
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…to dennybaa-setuptools-fixes
…ements to preserve a stable order.
…e common code to "dist_utils.py" module and copy this module over to each component package directory during build step. Update affected code.
…es to each component package directory.
…posed from README and CHANGELOG file.
…or each st2 component.
st2_version file. Note: For now we just copy over global __init__.py from st2common during build preparation step.
Setuptools packaging improvements - make each st2 component packagable and installable via package
…in each component directory.
…ways use correct and latest version of pip. Also update virtualenv target to install latest version of pip instead of doing it in the requirements target.
…y so it doesn't include changelog in the package description.
requirements.txt.
… target also works locally in a vagrant vm.
…ges under virtualenv.
| # Make sure we use latest version of pip | ||
| $(VIRTUALENV_DIR)/bin/pip install --upgrade pip | ||
|
|
||
| # Install stdeb st2client build dependency |
There was a problem hiding this comment.
It's a Python package we use in combination with setup.py to build a Debian package for st2client.
I wasn't aware of it before yesterday either. I added it here to make "make deb" self sustaining and now it also works in a local environment. Previously, this package would only magically get installed inside one of our CI workflows...
Kami
force-pushed
the
setuptools_packaging_improvements
branch
from
a39a38a to
210fa98
Compare
1 task
Kami
added a commit
that referenced
this pull request
Sep 2, 2015
duplicating the code across setup.py files. Note: This file is copied over from the common location to each component directory during the build step.
dennybaa
pushed a commit
to dennybaa/st2
that referenced
this pull request
Sep 2, 2015
…py instead of duplicating the code across setup.py files. Note: This file is copied over from the common location to each component directory during the build step.
|
This is not relevant anymore since #1917 was merged. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull requests builds on top of of #1647 and #1668.
I spent a lot of time finishing, polishing and testing all the changes from #1668 locally. Everything worked and looked fine so I decided to merge it into master. Sadly this turned out to be a mistake - there were many, many issues with packaging and other workflows used by our CI.
After 3-4 hours of digging in and fixing issues, I still haven't managed to fix all of them so I decided to revert changes in the master and unbreak it. I believe that's better than trying to rush to whole thing. Next step will be to address all the issues and run all the packaging and related workflows on this branch and only merge it into master when everything passes.
I will work with / ask @DoriftoShoes for help with running everything on a particular branch (not sure if we are there yet, might require some changes).
The biggest offenders currently are:
MANIFEST.inand replacing it with collecting all the code packages inside thesetup.pyfiles.This branch includes the following changes and improvements:
dist_utils.pymodule which is copied over to each component during build step and used inside setup.py instead of copy and pasting code over in setup.py.licenseandurlattribute.long_descriptionattribute to each setup.py file. This attribute is generated by combining togetherREADME.restandCHANGELOG.rstfile.sdistMakefilet target which generates.tar.gzandwheelarchive for each component.__versionattribute from each package init.py file. For now we simply copy over init.py from st2common. This way we don't break out existing release / build workflow, but eventually we should move to per-package version.flask,flask_json. This was actually done by @dennybaa, but I verified the changes and I'm pointing it out there to make it easier to track.requirements.txtfile. This way we make sure generated requirements files are always sorted the same.TO FIX: