On 11. 09. 20 0:23, Felix Schwarz wrote:
My main problem is shown at the end of this mail: Somehow the Python extras
subpackage name is bad but I don't know how to debug this (without spending a
lot of time).
The error is:
Error: The package name contains an extras name `easyname` that was not found
in the metadata.
The extras declared in pyproject.toml are:
[tool.poetry.extras]
namecheap = ["pynamecheap"]
route53 = ["boto3"]
transip = ["transip"]
plesk = ["xmltodict"]
localzone = ["localzone"]
softlayer = ["softlayer"]
gransy = ["zeep"]
# Extra "full" list must contain all other extras
full = ["pynamecheap", "boto3", "transip", "xmltodict", "localzone",
"softlayer", "zeep"]
Indeed, easyname does not exist here.
The changelog section has:
* The `beautifulsoup4` dependency has been integrated to the core
ones for generic purpose. As a consequence `henet`, `easyname` and `gratisdns`
providers do not have optional dependencies anymore.
As it seems, the henet, easyname and gratisdns extras were removed. (Which is
not consistent with what the changelog says.)
Maybe upstream is relying on the fact that pip happily installs any nonexistent
extra:
$ pip install 'dns-lexicon[hodor]==3.4'
...
Successfully installed dns-lexicon-3.4.0
I'd advise to keep the extras declared in upstream, as:
henet = []
easyname = []
gratisdns = []
See this note in setuptools documentation (final paragraph):
https://setuptools.readthedocs.io/en/latest/setuptools.html#declaring-extras-optional-features-with-their-own-dependencies
Note, by the way, that if a project ends up not needing any other packages
to support a feature, it should keep an empty requirements list for that
feature in its extras_require argument, so that packages depending on that >
feature don’t break (due to an invalid feature name).
You can workaround this on packaging level by removing the 3 subpackages and
adding this to the "main" package:
Obsoletes: python3-%{pypi_name}+gratisdns < 3.4
Provides: python3dist(%{pypi_name}[gratisdns]) = %{version}
Provides: python%{python3_version}dist(%{pypi_name}[gratisdns]) = %{version}
(repeat for all three)
Alternatively, since nothing in Fedora requires those, just obsolete them and be
done with it (don't add the provides).
------------
Additionally (but lower priority) just using %tox in %check fails (I think it
tries to download dependencies?).
The upstream's tox file has:
[testenv:light]
commands =
poetry install --no-root -v
I am afraid the %tox macro can only work with "static" deps declaration, not
with arbitrary installers invoked as commands, sorry about that. I have no idea
how this should be done "right" from upstream perspective :(
------------
Side note 0: I see the tox config also has:
[testenv]
extras =
dev
This is something the %pyproject_buildrequires don't understand yet, I'll open a
bugzilla.
------------
Side note 1: I see you have:
%pyproject_buildrequires ... -x route53 -x plesk
I am not sure this will work, as the macro only recently gained support for
multiple comma-separated extras passed as:
%pyproject_buildrequires ... -x route53,plesk
This was due to my false idea that RPM macros cannot handle repeated flags.
Apparently they can, so I'll open a bugzilla to adapt the script to support the
more natural way, thanks for the idea.
------------
Side note 2: I see you've put %generate_buildrequires near the other
buildrequires. I understand the sentiment, but the %generate_buildrequires
section happens between %prep and %build, so I highly recommend keeping the same
order in the spec file.
Thanks fro giving the new macros a try! Feel free to catch me in #fedora-python
tomorrow (I'm calling it a day after creating those bugzillas) if you'd like to
iterate in real time.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
