-
-
Notifications
You must be signed in to change notification settings - Fork 563
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
End to end approach for third-party packages handlings in ScanCode #2135
Comments
@pombredanne :
|
That looks good! Can you also try that on Linux and Python 3.7 too at least? |
@pombredanne if you place python 37/38 wheels from here to thirdparty . It will work on linux . |
When we run pip-compile ,the generated Requirement.txt is missing some package which is defined by
See this issue at jazzband/pip-tools#1202 |
Eventually we built a tool that handles creation, documentation and publishing of wheels and source https://github.com/nexB/scancode-toolkit/tree/1bddb92c70abcf26cf9435061e429bae62cbe040/etc/release Using romp it builds wheel and tests them on many OS/Python combos In the end they end up pushed to https://thirdparty.aboutcode.org/pypi/ |
When this all done, we will have NO files under thirdparty/ anymore.
Instead I will have:
all the wheels, source archives, ABOUT files and licenses, etc available for reference as release assets in some public GitHub PyPI-like repository that will be at https://github.com/nexB/third-party-packages/release
I have several requirements files with hashes, one per OS/Arch/Python combo for production.
I have one requirements file with hashes (supporting for all OS/Arch/Pythons combos) that is used for development only (e.g. it would have the tools we use under thirdparty/dev as well as new libraries such as pip-tools and similar)
For each release of ScanCode, I have the following assets attached to the scancode-toolkit release at https://github.com/nexB/scancode-toolkit/releases .This means:
In terms of what I can do:
This archive is an sdist-like archive and I can extract it and run as we can do it today with existing release archive. This archive is one of the 12 possible archives as listed in (4)
The other tickets are to actually create utilities to support these use case and to support scancode developers to automate the release operations.
Dev utility: build and download the sdist and wheels of a single package and all its dependencies Dev utility: build and download the sdist and wheels of a single package and all its dependencies #2087
Dev utility: Upload to GitHub release Dev utility: Upload to GitHub release #2136 ... this is also used by Dev utility: build and download the sdist and wheels of a single package and all its dependencies #2087
Dev utility: Create script to generate requirements with hashes Dev utility: Create script to generate requirements with hashes skeleton#50 in PR Automate the creation of requirement.txt and fetch deps #2118
Dev utility: Create release scripts to build archives Dev utility: Create release scripts to build archives #2072 part of PR Expose all .whl,.ABOUT, .NOTICE,.LICENCE files and Create an archive #2117
Dev utility: Improve configure script to work of pinned requirements Dev utility: Improve configure script to work of pinned requirements #2070
Dev utility: Create new repo to expose pre-built wheels, tarballs and ABOUT files as releases in a PyPI-like repo Dev utility: Create new repo to expose pre-built wheels, tarballs and ABOUT files as releases in a PyPI-like repo #2068
The text was updated successfully, but these errors were encountered: