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
SOURCE_DATE_EPOCH 0 can't be represented in zip timestamps #446
Comments
flit_core can build itself, with nothing besides Python! See PR #441, where I'm adding a document specifically on this topic. 😁 |
Hey, that's great news! I tried it and stumbled upon:
I presume this is because the date is set to Epoch 0, for reproducibility reasons. I tried setting all files mtime to ~1980, but in vain (unpacking the sdist, fixing up the mtimes and repacking it didn't help also). Strange. |
If the SOURCE_DATE_EPOCH environment variable is set when flit_core builds a wheel, it will use that for all the timestamps in the zip file, overriding any timestamps from the filesystem: I wasn't aware of the 1980 limitation. Is it possible to set SOURCE_DATE_EPOCH to something that works with zip files? If not, we can limit it to use 1980 if the supplied time is before then. |
@takluyver its a common practice in repeatable build distros like nix/guix to set the EPOCH to 0 as a default, that commonly creates issues with zip, auto-updating to a zip supported minimum is strongly recommended |
OK, we can do that. I assume 1980-1-1 00:00:00 is the timestamp we should use in that case. |
Take a look at PR #448. 🙂 (I've taken the liberty of updating the title of this issue to be specifically about handling SOURCE_DATE_EPOCH=0) |
Hi! Thanks for the update. It seems to work now: (define-public python-flit-core
;; Use the latest commit of the 'zip-date-min-1980' branch, as it includes
;; necessary fixes to the yet unreleased bootstrapping procedure defined in
;; the flit_core/build_dists.py script.
(let ((revision "0")
(commit "47c1b48b307f4c89fe9178b1fca2282950e213cb")
(version* "3.3.0"))
(package
(name "python-flit-core")
(version (git-version version* revision commit))
(source (origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/takluyver/flit")
(commit commit)))
(file-name (git-file-name name version))
(sha256
(base32
"01vg6ir0gla5zb8539rxn8zmczly3d6qh2mcfpjkihxqvqlrs6gr"))))
(build-system python-build-system)
(propagated-inputs
`(("python-toml" ,python-toml)))
(arguments
;; flit-core has a test suite, but it requires Pytest. Disable it so
;; as to not pull pytest as an input.
`(#:tests? #f
#:phases
(modify-phases %standard-phases
(replace 'build
;; flit-core requires itself to build. Luckily, a
;; bootstrapping script exists, which does so using just
;; the checkout sources and Python.
(lambda _
(invoke "python" "flit_core/build_dists.py")))
(replace 'install
(lambda* (#:key inputs outputs #:allow-other-keys)
(let ((out (assoc-ref outputs "out"))
(site (site-packages inputs outputs))
(whl (car (find-files "." "\\.whl$"))))
(mkdir-p site)
(invoke "unzip" "-d" site whl "-x" "flit_core/tests/*")
;; Byte compile the installed source files.
(invoke "python" "-m" "compileall"
"--invalidation-mode=unchecked-hash"
site)))))))
(native-inputs
`(("unzip" ,unzip)))
(home-page "https://github.com/takluyver/flit")
(synopsis "Core package of the Flit Python build system")
(description "This package provides @code{flit-core}, a PEP 517 build
backend for packages using Flit. The only public interface is the API
specified by PEP 517, @code{flit_core.buildapi}.")
(license license:bsd-3)))) Produces:
|
Hmm. Does flit really requires tomli ? Now the issue has moved to trying to build a minimal tomli, which requires flit, which requires tomli:
|
Perhaps I can s/tomli/toml/ to workaround this (they share the same API, right?), as toml has no bootstrap requirements else than the (already bundled) setuptools that is shipped with Python itself. |
flit_core can build itself without a TOML parser, but then it requires tomli to build anything else - including tomli itself. It should be possible to make this work by letting it import tomli from the source directory while building tomli. I've tried to explain this in a the bootstrapping doc on #441 . I'm hoping that ultimately this little wrinkle will be ironed out by having a TOML parser in the standard library, but that will take a while. |
Hello! I was able to build it, but I'm a bit puzzled as to why pypa build cannot find flit_core >= 3.2.0 <4 (the files installed are listed above). Any idea? It can be worked around with -x (--skip-dependency-check).
|
I'm not sure about that either. I think this is the relevant code in build if you want to investigate: But I'd expect you'd need to skip the dependency check when building tomli in any case, because the workaround to make tomli importable doesn't make it appear as an installed distribution. So if this only affects building tomli, I'd just accept that the error message is mistaken. If you see the same thing when building normal packages without this trick, it's worth figuring out what's happening. |
I see this is fixed in 3.4.0. Thanks! It works. |
Hello,
I wanted to package flit-core for Guix, but even flit-core requires flit to be built, according to pyproject.toml. Is there an older release of flit-core that could be built simply using setuptools or another way? That'd allow us to have a clear bootstrapping path to flit.
Ideally, perhaps flit-core could be made to always build with something else than itself to fix this bootstrapping problem.
Thanks for your consideration!
The text was updated successfully, but these errors were encountered: