-
Notifications
You must be signed in to change notification settings - Fork 12
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
pip-21.0.1 is breaking reproducible wheels #218
Comments
Thanks for opening the issue @kushaldas . Right now, the |
Yes, that is why I mentioned to use latest |
$ python -m build --wheel ./simplejson-3.17.2 --no-build-isolation
...
$ shasum -a 256 ./simplejson-3.17.2/dist/simplejson-3.17.2-cp38-cp38-macosx_10_9_x86_64.whl
6bbb49faf3a94233d3e1dd5059040b939169f2485426cbbef97dfbfa0ecda1ee ./simplejson-3.17.2/dist/simplejson-3.17.2-cp38-cp38-macosx_10_9_x86_64.whl
$ python -m build --wheel ./simplejson-3.17.2 --no-build-isolation
...
$ shasum -a 256 ./simplejson-3.17.2/dist/simplejson-3.17.2-cp38-cp38-macosx_10_9_x86_64.whl
6bbb49faf3a94233d3e1dd5059040b939169f2485426cbbef97dfbfa0ecda1ee ./simplejson-3.17.2/dist/simplejson-3.17.2-cp38-cp38-macosx_10_9_x86_64.whl
$ python -m build --wheel ./simplejson-3.17.2
...
$ shasum -a 256 ./simplejson-3.17.2/dist/simplejson-3.17.2-cp38-cp38-macosx_10_9_x86_64.whl
6bbb49faf3a94233d3e1dd5059040b939169f2485426cbbef97dfbfa0ecda1ee ./simplejson-3.17.2/dist/simplejson-3.17.2-cp38-cp38-macosx_10_9_x86_64.whl @kushaldas and I were chatting about this today, and... figured out how to get reproducibility with |
Well, I only needed to |
This was strange
I think due to the user who unpacked the tarball. |
I am finally getting same wheel, but had to remember to use the similar kind of non-root user while building. Used the following script to test. Remember to have latest
|
One remaining question is about build dependencies of any package, but I will know more about it in future. For example: if package A depends on package B and C as build dependency, how does |
Found one build dependency related failure:
|
❔ ❔ I think this is better for the whole isolation, as till now these dependencies were down via
|
Final verdict from the
--- /tmp/tmp6zddqn9p/control
+++ /tmp/tmp6zddqn9p/experiment-1
___ source-root
_ ___ localwheels
_ _ ___ idna-2.7-py2.py3-none-any.whl
_ _ _ ___ zipinfo /dev/stdin
_ _ _ _ @@ -3,13 +3,13 @@
_ _ _ _ -rw-r--r-- 2.0 unx 3299 b- defN 11-Jun-29 20:23 idna/codec.py
_ _ _ _ -rw-r--r-- 2.0 unx 232 b- defN 11-Jun-29 20:23 idna/compat.py
_ _ _ _ -rw-r--r-- 2.0 unx 11858 b- defN 11-Jun-29 20:23 idna/core.py
_ _ _ _ -rw-r--r-- 2.0 unx 39285 b- defN 11-Jun-29 20:23 idna/idnadata.py
_ _ _ _ -rw-r--r-- 2.0 unx 1749 b- defN 11-Jun-29 20:23 idna/intranges.py
_ _ _ _ -rw-r--r-- 2.0 unx 21 b- defN 11-Jun-29 20:23 idna/package_data.py
_ _ _ _ -rw-r--r-- 2.0 unx 197803 b- defN 11-Jun-29 20:23 idna/uts46data.py
_ _ _ _ --rwx------ 2.0 unx 3947 b- defN 11-Jun-29 20:23 idna-2.7.dist-info/LICENSE.rst
_ _ _ _ +-rw-r--r-- 2.0 unx 3947 b- defN 11-Jun-29 20:23 idna-2.7.dist-info/LICENSE.rst
_ _ _ _ -rw-r--r-- 2.0 unx 8866 b- defN 11-Jun-29 20:23 idna-2.7.dist-info/METADATA
_ _ _ _ -rw-r--r-- 2.0 unx 110 b- defN 11-Jun-29 20:23 idna-2.7.dist-info/WHEEL
_ _ _ _ --rwx------ 2.0 unx 5 b- defN 11-Jun-29 20:23 idna-2.7.dist-info/top_level.txt
_ _ _ _ +-rw-r--r-- 2.0 unx 5 b- defN 11-Jun-29 20:23 idna-2.7.dist-info/top_level.txt
_ _ _ _ ?rw-rw-r-- 2.0 unx 945 b- defN 11-Jun-29 20:23 idna-2.7.dist-info/RECORD
_ _ _ _ 13 files, 268178 bytes uncompressed, 56674 bytes compressed: 78.9%
second error--- /tmp/tmpfsnhm73k/control
+++ /tmp/tmpfsnhm73k/experiment-1
___ source-root
_ ___ localwheels
_ _ ___ Mako-1.0.7-py3-none-any.whl
_ _ _ ___ zipinfo /dev/stdin
_ _ _ _ @@ -21,15 +21,15 @@
_ _ _ _ -rw-r--r-- 2.0 unx 2079 b- defN 11-Jun-29 20:23 mako/ext/babelplugin.py
_ _ _ _ -rw-r--r-- 2.0 unx 2365 b- defN 11-Jun-29 20:23 mako/ext/beaker_cache.py
_ _ _ _ -rw-r--r-- 2.0 unx 4261 b- defN 11-Jun-29 20:23 mako/ext/extract.py
_ _ _ _ -rw-r--r-- 2.0 unx 1663 b- defN 11-Jun-29 20:23 mako/ext/linguaplugin.py
_ _ _ _ -rw-r--r-- 2.0 unx 580 b- defN 11-Jun-29 20:23 mako/ext/preprocessors.py
_ _ _ _ -rw-r--r-- 2.0 unx 4530 b- defN 11-Jun-29 20:23 mako/ext/pygmentplugin.py
_ _ _ _ -rw-r--r-- 2.0 unx 2132 b- defN 11-Jun-29 20:23 mako/ext/turbogears.py
_ _ _ _ --rw-rw-r-- 2.0 unx 282 b- defN 11-Jun-29 20:23 Mako-1.0.7.dist-info/AUTHORS
_ _ _ _ --rw-rw-r-- 2.0 unx 1217 b- defN 11-Jun-29 20:23 Mako-1.0.7.dist-info/LICENSE
_ _ _ _ +-rw-r--r-- 2.0 unx 282 b- defN 11-Jun-29 20:23 Mako-1.0.7.dist-info/AUTHORS
_ _ _ _ +-rw-r--r-- 2.0 unx 1217 b- defN 11-Jun-29 20:23 Mako-1.0.7.dist-info/LICENSE
_ _ _ _ -rw-r--r-- 2.0 unx 2233 b- defN 11-Jun-29 20:23 Mako-1.0.7.dist-info/METADATA
_ _ _ _ -rw-r--r-- 2.0 unx 92 b- defN 11-Jun-29 20:23 Mako-1.0.7.dist-info/WHEEL
_ _ _ _ --rw-rw-r-- 2.0 unx 586 b- defN 11-Jun-29 20:23 Mako-1.0.7.dist-info/entry_points.txt
_ _ _ _ --rw-rw-r-- 2.0 unx 5 b- defN 11-Jun-29 20:23 Mako-1.0.7.dist-info/top_level.txt
_ _ _ _ +-rw-r--r-- 2.0 unx 586 b- defN 11-Jun-29 20:23 Mako-1.0.7.dist-info/entry_points.txt
_ _ _ _ +-rw-r--r-- 2.0 unx 5 b- defN 11-Jun-29 20:23 Mako-1.0.7.dist-info/top_level.txt
_ _ _ _ ?rw-rw-r-- 2.0 unx 2484 b- defN 11-Jun-29 20:23 Mako-1.0.7.dist-info/RECORD
_ _ _ _ 33 files, 273001 bytes uncompressed, 72733 bytes compressed: 73.4%
_ _ ___ SQLAlchemy-1.3.3-cp37-cp37m-linux_x86_64.whl
_ _ _ ___ zipinfo /dev/stdin
_ _ _ _ @@ -191,13 +191,13 @@
_ _ _ _ -rw-r--r-- 2.0 unx 6580 b- defN 11-Jun-29 20:23 sqlalchemy/util/__init__.py
_ _ _ _ -rw-r--r-- 2.0 unx 29153 b- defN 11-Jun-29 20:23 sqlalchemy/util/_collections.py
_ _ _ _ -rw-r--r-- 2.0 unx 11264 b- defN 11-Jun-29 20:23 sqlalchemy/util/compat.py
_ _ _ _ -rw-r--r-- 2.0 unx 7169 b- defN 11-Jun-29 20:23 sqlalchemy/util/deprecations.py
_ _ _ _ -rw-r--r-- 2.0 unx 47645 b- defN 11-Jun-29 20:23 sqlalchemy/util/langhelpers.py
_ _ _ _ -rw-r--r-- 2.0 unx 6827 b- defN 11-Jun-29 20:23 sqlalchemy/util/queue.py
_ _ _ _ -rw-r--r-- 2.0 unx 2767 b- defN 11-Jun-29 20:23 sqlalchemy/util/topological.py
_ _ _ _ --rw-rw-r-- 2.0 unx 1229 b- defN 11-Jun-29 20:23 SQLAlchemy-1.3.3.dist-info/LICENSE
_ _ _ _ +-rw-r--r-- 2.0 unx 1229 b- defN 11-Jun-29 20:23 SQLAlchemy-1.3.3.dist-info/LICENSE
_ _ _ _ -rw-r--r-- 2.0 unx 7122 b- defN 11-Jun-29 20:23 SQLAlchemy-1.3.3.dist-info/METADATA
_ _ _ _ -rw-r--r-- 2.0 unx 104 b- defN 11-Jun-29 20:23 SQLAlchemy-1.3.3.dist-info/WHEEL
_ _ _ _ --rw-rw-r-- 2.0 unx 11 b- defN 11-Jun-29 20:23 SQLAlchemy-1.3.3.dist-info/top_level.txt
_ _ _ _ +-rw-r--r-- 2.0 unx 11 b- defN 11-Jun-29 20:23 SQLAlchemy-1.3.3.dist-info/top_level.txt
_ _ _ _ ?rw-rw-r-- 2.0 unx 17870 b- defN 11-Jun-29 20:23 SQLAlchemy-1.3.3.dist-info/RECORD
_ _ _ _ 201 files, 4616863 bytes uncompressed, 1159855 bytes compressed: 74.9%
_ _ ___ alembic-1.0.2-py2.py3-none-any.whl
_ _ _ ___ zipinfo /dev/stdin
_ _ _ _ @@ -25,26 +25,26 @@
_ _ _ _ -rw-r--r-- 2.0 unx 4870 b- defN 11-Jun-29 20:23 alembic/operations/toimpl.py
_ _ _ _ -rw-r--r-- 2.0 unx 0 b- defN 11-Jun-29 20:23 alembic/runtime/__init__.py
_ _ _ _ -rw-r--r-- 2.0 unx 37944 b- defN 11-Jun-29 20:23 alembic/runtime/environment.py
_ _ _ _ -rw-r--r-- 2.0 unx 34983 b- defN 11-Jun-29 20:23 alembic/runtime/migration.py
_ _ _ _ -rw-r--r-- 2.0 unx 91 b- defN 11-Jun-29 20:23 alembic/script/__init__.py
_ _ _ _ -rw-r--r-- 2.0 unx 30424 b- defN 11-Jun-29 20:23 alembic/script/base.py
_ _ _ _ -rw-r--r-- 2.0 unx 32534 b- defN 11-Jun-29 20:23 alembic/script/revision.py
_ _ _ _ --rw-rw-r-- 2.0 unx 38 b- defN 11-Jun-29 20:23 alembic/templates/generic/README
_ _ _ _ --rw-rw-r-- 2.0 unx 1680 b- defN 11-Jun-29 20:23 alembic/templates/generic/alembic.ini.mako
_ _ _ _ --rw-rw-r-- 2.0 unx 1990 b- defN 11-Jun-29 20:23 alembic/templates/generic/env.py
_ _ _ _ --rw-rw-r-- 2.0 unx 494 b- defN 11-Jun-29 20:23 alembic/templates/generic/script.py.mako
_ _ _ _ --rw-rw-r-- 2.0 unx 41 b- defN 11-Jun-29 20:23 alembic/templates/multidb/README
_ _ _ _ --rw-rw-r-- 2.0 unx 1775 b- defN 11-Jun-29 20:23 alembic/templates/multidb/alembic.ini.mako
_ _ _ _ --rw-rw-r-- 2.0 unx 4147 b- defN 11-Jun-29 20:23 alembic/templates/multidb/env.py
_ _ _ _ --rw-rw-r-- 2.0 unx 923 b- defN 11-Jun-29 20:23 alembic/templates/multidb/script.py.mako
_ _ _ _ --rw-rw-r-- 2.0 unx 59 b- defN 11-Jun-29 20:23 alembic/templates/pylons/README
_ _ _ _ --rw-rw-r-- 2.0 unx 1159 b- defN 11-Jun-29 20:23 alembic/templates/pylons/alembic.ini.mako
_ _ _ _ --rw-rw-r-- 2.0 unx 2221 b- defN 11-Jun-29 20:23 alembic/templates/pylons/env.py
_ _ _ _ --rw-rw-r-- 2.0 unx 494 b- defN 11-Jun-29 20:23 alembic/templates/pylons/script.py.mako
_ _ _ _ +-rw-r--r-- 2.0 unx 38 b- defN 11-Jun-29 20:23 alembic/templates/generic/README
_ _ _ _ +-rw-r--r-- 2.0 unx 1680 b- defN 11-Jun-29 20:23 alembic/templates/generic/alembic.ini.mako
_ _ _ _ +-rw-r--r-- 2.0 unx 1990 b- defN 11-Jun-29 20:23 alembic/templates/generic/env.py
_ _ _ _ +-rw-r--r-- 2.0 unx 494 b- defN 11-Jun-29 20:23 alembic/templates/generic/script.py.mako
_ _ _ _ +-rw-r--r-- 2.0 unx 41 b- defN 11-Jun-29 20:23 alembic/templates/multidb/README
_ _ _ _ +-rw-r--r-- 2.0 unx 1775 b- defN 11-Jun-29 20:23 alembic/templates/multidb/alembic.ini.mako
_ _ _ _ +-rw-r--r-- 2.0 unx 4147 b- defN 11-Jun-29 20:23 alembic/templates/multidb/env.py
_ _ _ _ +-rw-r--r-- 2.0 unx 923 b- defN 11-Jun-29 20:23 alembic/templates/multidb/script.py.mako
_ _ _ _ +-rw-r--r-- 2.0 unx 59 b- defN 11-Jun-29 20:23 alembic/templates/pylons/README
_ _ _ _ +-rw-r--r-- 2.0 unx 1159 b- defN 11-Jun-29 20:23 alembic/templates/pylons/alembic.ini.mako
_ _ _ _ +-rw-r--r-- 2.0 unx 2221 b- defN 11-Jun-29 20:23 alembic/templates/pylons/env.py
_ _ _ _ +-rw-r--r-- 2.0 unx 494 b- defN 11-Jun-29 20:23 alembic/templates/pylons/script.py.mako
_ _ _ _ -rw-r--r-- 2.0 unx 253 b- defN 11-Jun-29 20:23 alembic/testing/__init__.py
_ _ _ _ -rw-r--r-- 2.0 unx 5931 b- defN 11-Jun-29 20:23 alembic/testing/assertions.py
_ _ _ _ -rw-r--r-- 2.0 unx 310 b- defN 11-Jun-29 20:23 alembic/testing/compat.py
_ _ _ _ -rw-r--r-- 2.0 unx 2544 b- defN 11-Jun-29 20:23 alembic/testing/config.py
_ _ _ _ -rw-r--r-- 2.0 unx 766 b- defN 11-Jun-29 20:23 alembic/testing/engines.py
_ _ _ _ -rw-r--r-- 2.0 unx 9485 b- defN 11-Jun-29 20:23 alembic/testing/env.py
_ _ _ _ -rw-r--r-- 2.0 unx 12825 b- defN 11-Jun-29 20:23 alembic/testing/exclusions.py
_ _ _ _ @@ -63,14 +63,14 @@
_ _ _ _ -rw-r--r-- 2.0 unx 687 b- defN 11-Jun-29 20:23 alembic/util/__init__.py
_ _ _ _ -rw-r--r-- 2.0 unx 6822 b- defN 11-Jun-29 20:23 alembic/util/compat.py
_ _ _ _ -rw-r--r-- 2.0 unx 40 b- defN 11-Jun-29 20:23 alembic/util/exc.py
_ _ _ _ -rw-r--r-- 2.0 unx 9640 b- defN 11-Jun-29 20:23 alembic/util/langhelpers.py
_ _ _ _ -rw-r--r-- 2.0 unx 2442 b- defN 11-Jun-29 20:23 alembic/util/messaging.py
_ _ _ _ -rw-r--r-- 2.0 unx 2677 b- defN 11-Jun-29 20:23 alembic/util/pyfiles.py
_ _ _ _ -rw-r--r-- 2.0 unx 6718 b- defN 11-Jun-29 20:23 alembic/util/sqla_compat.py
_ _ _ _ --rw-rw-r-- 2.0 unx 1184 b- defN 11-Jun-29 20:23 alembic-1.0.2.dist-info/LICENSE
_ _ _ _ +-rw-r--r-- 2.0 unx 1184 b- defN 11-Jun-29 20:23 alembic-1.0.2.dist-info/LICENSE
_ _ _ _ -rw-r--r-- 2.0 unx 6038 b- defN 11-Jun-29 20:23 alembic-1.0.2.dist-info/METADATA
_ _ _ _ -rw-r--r-- 2.0 unx 110 b- defN 11-Jun-29 20:23 alembic-1.0.2.dist-info/WHEEL
_ _ _ _ --rw-rw-r-- 2.0 unx 49 b- defN 11-Jun-29 20:23 alembic-1.0.2.dist-info/entry_points.txt
_ _ _ _ --rw-rw-r-- 2.0 unx 8 b- defN 11-Jun-29 20:23 alembic-1.0.2.dist-info/top_level.txt
_ _ _ _ +-rw-r--r-- 2.0 unx 49 b- defN 11-Jun-29 20:23 alembic-1.0.2.dist-info/entry_points.txt
_ _ _ _ +-rw-r--r-- 2.0 unx 8 b- defN 11-Jun-29 20:23 alembic-1.0.2.dist-info/top_level.txt
_ _ _ _ ?rw-rw-r-- 2.0 unx 6225 b- defN 11-Jun-29 20:23 alembic-1.0.2.dist-info/RECORD
_ _ _ _ 74 files, 571968 bytes uncompressed, 146419 bytes compressed: 74.4%
_ _ ___ idna-2.7-py2.py3-none-any.whl
_ _ _ ___ zipinfo /dev/stdin
_ _ _ _ @@ -3,13 +3,13 @@
_ _ _ _ -rw-r--r-- 2.0 unx 3299 b- defN 11-Jun-29 20:23 idna/codec.py
_ _ _ _ -rw-r--r-- 2.0 unx 232 b- defN 11-Jun-29 20:23 idna/compat.py
_ _ _ _ -rw-r--r-- 2.0 unx 11858 b- defN 11-Jun-29 20:23 idna/core.py
_ _ _ _ -rw-r--r-- 2.0 unx 39285 b- defN 11-Jun-29 20:23 idna/idnadata.py
_ _ _ _ -rw-r--r-- 2.0 unx 1749 b- defN 11-Jun-29 20:23 idna/intranges.py
_ _ _ _ -rw-r--r-- 2.0 unx 21 b- defN 11-Jun-29 20:23 idna/package_data.py
_ _ _ _ -rw-r--r-- 2.0 unx 197803 b- defN 11-Jun-29 20:23 idna/uts46data.py
_ _ _ _ --rwx------ 2.0 unx 3947 b- defN 11-Jun-29 20:23 idna-2.7.dist-info/LICENSE.rst
_ _ _ _ +-rw-r--r-- 2.0 unx 3947 b- defN 11-Jun-29 20:23 idna-2.7.dist-info/LICENSE.rst
_ _ _ _ -rw-r--r-- 2.0 unx 8866 b- defN 11-Jun-29 20:23 idna-2.7.dist-info/METADATA
_ _ _ _ -rw-r--r-- 2.0 unx 110 b- defN 11-Jun-29 20:23 idna-2.7.dist-info/WHEEL
_ _ _ _ --rwx------ 2.0 unx 5 b- defN 11-Jun-29 20:23 idna-2.7.dist-info/top_level.txt
_ _ _ _ +-rw-r--r-- 2.0 unx 5 b- defN 11-Jun-29 20:23 idna-2.7.dist-info/top_level.txt
_ _ _ _ ?rw-rw-r-- 2.0 unx 945 b- defN 11-Jun-29 20:23 idna-2.7.dist-info/RECORD
_ _ _ _ 13 files, 268178 bytes uncompressed, 56674 bytes compressed: 78.9%
FAILED
third error (we are missing system level dependency)
|
FWIW, you arguably have more control with build, since you can use the API and have a custom isolated environment, that installs from wheels that you've built with a reproducible process. |
Uh, nop. It doesn't currently 😕. I really want that, but currently we use pip to install into our isolated environment. I was considering maybe using |
Ahhh, nevermind. I just woke up and can't read straight 😅. Yeah, you can use the API to install the wheels you've built, but they won't necessarily be installed in a reproducible way. I guess that unreproduceability could leak into your build process, but I don't think it should be that much of a problem. |
@kushaldas Are you setting umask? The scripts in this repo force umask to avoid variance like what you describe, see https://github.com/freedomofpress/securedrop-debian-packaging/blob/9fb5e7f739ec16b02d1d25ee88137c84702ce388/scripts/build-sync-wheels#L19-L20 If you have specific STR, or better yet, a branch, please share!
My understanding is that if the wheels themselves are reproducibly built, that's all we need to get fully reproducible debian packages. At least, the variation in metadata within the wheels was the last bit of non-determinism we had to track down and stamp out, in #211 and #213. |
Somehow the temporary directory is getting cleaned up. Look at the directory content at the top and then after build:
|
|
Next big question:
@conorsch any tips on how to extract the files? |
If you're running |
@conorsch try this branch: https://github.com/freedomofpress/securedrop-debian-packaging/tree/build_with_build
Finally this works somewhat. |
Notation: We will need to use build tool to create the wheels. In this branch I already created the minimal requirements file for the tool itself. The steps required: bootstrapping
Actual wheels rebuilding
We should regenerate wheels for all of the Debian pacakges and recreate their CI side of work
|
Interesting, I wonder what's different about the structure of the emitted wheels. Thanks for pushing a branch, I'll run through the steps you describe and compare wheels of the same package versions via |
Took a look, and the new build logic is promising! The only variation I noticed in the emitted wheels was for packages that include
All other wheels had the same hash. I appended some commits required to get things working on my machine, such as including the
Once we resolve that, we're in a good place to rebuild the wheels and use the new logic. |
Ah, this dependency is new I guess. I am working to add it as a dependency. |
I was testing with
|
After more digging today I can see the difference of 8 bytes happening at the
@conorsch my suggestion is to rebuild all the wheels. Let me know what do you think. |
Shouldn't the source directory path not be a function of the built artifact? Is there a way to override this? @kushaldas we had a similar issue with updating/matching paths and reproducibility in #231 . This seems to me like a regression, as we were able to build package in a way that is reproducible, regardless of the path where the packaging repo was cloned. |
If the diff is as small as the 8bytes in the header, if this is the way that source paths will be handled in the future, then yes, let's rebuild those wheels.
Agreed, because the wheels will be reproducible (and we will have CI check to ensure that the wheels are reproducible), it does make sense to have developers sign with their personal keys. In the future, we can consider CI building these wheel on request, and have a developer compare the hash of the wheel with their local build, sign and merge.
About the bootstrapping, how will we ensure the initial build is correct? This sounds to me like a potential chicken-and-egg problem where we need to build Another thing to consider: If the end result of the build process is the same (e.g. same wheel or deb package hash), does it matter if we use the pypi wheel (or instead just use the non-reproducibly-built-from-source) |
i don't think it is. i think it might be better to just maintain the wheels that have different hashes so that we can easily find which wheels we had to do diff reviews for in case we need to re-review. |
Oops I misunderstood your question. I thought you were asking if we should push another set of wheels with the same hashes for our projects just because they were built with Should we maintain a set of reproducible wheels of the |
We will count the source tarballs for That is why my initial step is called bootstrapping, where we create the wheels for |
We will have to rebiuld the wheels as there will be a few wheels with new sha256sums.
The idea is to isolate the whole building environment. We need to make sure that we are using a valid set of packages, and maintaining a copy of all required wheel building tools in a local cache is generally the standard way to create such isolate building environment. |
Timing informationInstalling from source on a Xeon server:
From wheels
|
FWIW, pip should internally be building a wheel and installing from it, when installing from an sdist -- so it's generally better to directly install from the wheel. Especially since wheel-based installs are deterministic and don't involve executing any code. |
We finished the first step of bootstrapping, next we will have to regenerate all the wheels, and then also create
We should discuss the steps during our standup today. @creviera @conorsch |
Now that #238 is merged, we're good to close. We have a bit more follow-up, e.g. #241, tracked separately. Thanks, @kushaldas & @creviera, for getting these improvements in. And thanks also to @pradyunsg & @FFY00 for the helpful guidance! |
The
--build
is now deprecated. Tracking it in the upstream issue pypa/pip#9604Note: we should add a monthly CI job to to test reproducibility using the latest
setuptools
andpip
.The text was updated successfully, but these errors were encountered: