Invalid version detection when using setuptools_scm + pyproject #154
Comments
|
I end up using the variable that was in place for the dependencies that required Not sure if the alternative is to keep adding those. If so... then maybe I could create a PR with cyraxjoe@f6de689 |
|
After realizing that those can be easily overridden with something like: poetry2nix.overrides.withDefaults (
self: super: {
jaraco-functools = super.jaraco-functools.overridePythonAttrs (
old: {
dontPreferSetupPy = true;
}
);
tempora = super.tempora.overridePythonAttrs (
old: {
dontPreferSetupPy = true;
}
);
portend = super.portend.overridePythonAttrs (
old: {
dontPreferSetupPy = true;
}
);
}
)I'm thinking that maybe is more of a documentation thing, something like mentioning the potential need of explicitly preserving the |
This The true proper fix to all of this is to fix Poetry to manage dependencies used when building from source, though that's obviously a lot more work than hacking around the issue. |
For now that would be great! |
Re the "code solution" we cannot do that as that would require fetching the dependency at eval time and introspect the toml file, resulting in IFD (import from derivation) which has some pretty nasty implications. Re documentation I agree, I would love to have a few tutorial style docs where we could explain these quite complicated things. |
|
FYI there is a draft PR to support build-system requirements in Poetry: python-poetry/poetry#2794 |
|
Closed in #513 |
Apparently poetry2nix is unable to detect the proper version of the package when the package distributes a source package with
pyproject.toml(included by default in thesdistpackages from setuptools) and the package is using setuptools_scm with thetomlextra, which relies on having the pyproject file in the source distribution.An example of a package that will cause problems when used as a depedency in poetry2nix is jaraco.functools, which has this pyproject.toml, building a wheel from the sdist of
jaraco.functoolseither withpython setup.py wheelorpip wheelwithout thepyproject.tomlwill end up with a wheel with version0.0.0, messing up the following build, because the dependency at the expected version is not met.The removal happens specifically at this hook script https://github.com/nix-community/poetry2nix/blob/master/hooks/pip-build-hook.sh#L8, I'm not sure what are the implications of not removing the
pyproject.tomlbut given the new default of including the pyproject in the source distribution, I think that more and more packages will start to relay in the presence of that file, the simple removal of the file seems that will cause additional surprises in the future.The issue can be replicated with:
Empty
fooapp.pyfile.pyproject.toml:poetry.lock:default.nix:The build will result in something similar to:
The text was updated successfully, but these errors were encountered: