Re: External (non-rpm) BuidRequires - was New Mock release v2.7

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/2/20 2:13 PM, Miroslav Suchý wrote:
Dne 02. 12. 20 v 11:51 Miro Hrončok napsal(a):
I can imagine myself using this locally when some test dependencies are missing (e.g. in RHEL). I hope it's possible to
use this with `mock --install` and not just as BuildRequires. It is not clear from the linked GH wiki page.

I did not thought about this. Should be easy to implement. Tracked here:
  https://github.com/rpm-software-management/mock/issues/671


1) Can I specify version ranges? Do I use RPM or Python syntax?

Version of module? Or version of python?

Version of the buildrequired PyPI package. E.g. "external:pypi:dnspython < 2".

(I assume this is what you've meant by "version of module".)


Python version will be whatever Python version pip is for. That's fine.

If support for multiple Python versions (e.g. for RHEL) is desired, passing custom pip package / command needs to be supported, e.g. via config_opts['external_buildrequires_pypi_required_packages'] and config_opts['external_buildrequires_pypi_install_command'].

No. You cannot. Neither of them.
Can you point me to differences between RPM and Python syntax of version ranges?

It's complicated :)

See https://github.com/gordonmessmer/pyreq2rpm/ for a best-effort conversion from Python package version specifiers to the RPM ones. The dependency generator uses this.

2) I've read that a temporary RPM package is created:

To satisfy rpm dependencies Mock calls create-fake-rpm and creates a fake rpm
package that provides external:pypi:foo and installs it in chroot.

Does the fake RPM provide pytohn3.9dist(foo)?

No. It does not. The fake rpm is there only to provide the string "external:pypi:*' so rpmbuild will proceed with building.
I can enhance it to provide pytohn3.9dist(foo). How can I get that 3.9 number?
I tried to look through existing macros and I tried to fiddle with /usr/lib/rpm/pythondistdeps.py but it does not ring
the bell.

If you can get the list of files installed by pip (pip knows them), you could run the dependency generator directly upon them.

This somehow gives the files, except you need to join Location and Files.

    $ python -m pip show -f appdirs

Running the generator is:

    $ echo /usr/lib/python3.9/site-packages/appdirs-1.4.3.dist-info/* | \
    /usr/lib/rpm/pythondistdeps.py --provides \
    --normalized-names-format pep503 --normalized-names-provide-both \
    --majorver-provides-versions 2.7,3.9
    python3.9dist(appdirs) = 1.4.3
    python3dist(appdirs) = 1.4.3

However, since the buildrequired pypi packages can also bring in other packages, it's not that simple.

Also, that command's options will differ from buildroot to buildroot.

Should it?

I do not know. Should? :) I think it should. As it is build requirements it is welcomed and safe. Run time requirement
would be different case.

Tracked as:
https://github.com/rpm-software-management/mock/issues/672

Thank you for the feedback.



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux