Jeff Fearn reminded me today of "mock --megadeps", a patched version of mock he created that supports recursively downloading and building dependencies in a chroot, without incurring the overhead of setting up and tearing down multiple mock build environments the way the chainbuild command does.
The mock RFE is at https://bugzilla.redhat.com/show_bug.cgi?id=843745, while Jeff is now maintaining the patched version at https://github.com/jfearn/mock
I'm bringing this to folks attention mainly due to one of the neat features it has embedded in it, which is integration with CPAN: it can use cpanspec to create an SRPM on the fly. That's likely not going to be of suitable quality for Fedora itself, but it should be good enough for COPR and potentially even Playground.
My question is whether it would be practical to do something similar with pyp2rpm. Bonus points if we can come up with a way to integrate it nicely with COPR, or even tidy up the implementation to the point where we can convince Clark to accept the feature as part of mock itself :)
Regards, Nick.
----- Original Message -----
From: "Nick Coghlan" ncoghlan@redhat.com To: "Fedora Python SIG" python-devel@lists.fedoraproject.org Sent: Thursday, August 21, 2014 2:35:48 AM Subject: mock, "megadeps" and PyPI
Jeff Fearn reminded me today of "mock --megadeps", a patched version of mock he created that supports recursively downloading and building dependencies in a chroot, without incurring the overhead of setting up and tearing down multiple mock build environments the way the chainbuild command does.
The mock RFE is at https://bugzilla.redhat.com/show_bug.cgi?id=843745, while Jeff is now maintaining the patched version at https://github.com/jfearn/mock
I'm bringing this to folks attention mainly due to one of the neat features it has embedded in it, which is integration with CPAN: it can use cpanspec to create an SRPM on the fly. That's likely not going to be of suitable quality for Fedora itself, but it should be good enough for COPR and potentially even Playground.
My question is whether it would be practical to do something similar with pyp2rpm. Bonus points if we can come up with a way to integrate it nicely with COPR, or even tidy up the implementation to the point where we can convince Clark to accept the feature as part of mock itself :)
Hi Nick,
I have created vague named issue[0] at pyp2rpm repo we can discuss it there. I will post my opinion later, next week probably, currently I am off from work.
Regards, Nick.
-- Nick Coghlan Red Hat Hosted & Shared Services Software Engineering & Development, Brisbane
HSS Provisioning Architect _______________________________________________ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Regards,
Robert Kuska ----------------------------------------------------- rkuska @ #fedora-devel on freenode #brno #gulag #software-collections on brq.redhat
----- Original Message -----
----- Original Message -----
From: "Nick Coghlan" ncoghlan@redhat.com To: "Fedora Python SIG" python-devel@lists.fedoraproject.org Sent: Thursday, August 21, 2014 2:35:48 AM Subject: mock, "megadeps" and PyPI
Jeff Fearn reminded me today of "mock --megadeps", a patched version of mock he created that supports recursively downloading and building dependencies in a chroot, without incurring the overhead of setting up and tearing down multiple mock build environments the way the chainbuild command does.
The mock RFE is at https://bugzilla.redhat.com/show_bug.cgi?id=843745, while Jeff is now maintaining the patched version at https://github.com/jfearn/mock
I'm bringing this to folks attention mainly due to one of the neat features it has embedded in it, which is integration with CPAN: it can use cpanspec to create an SRPM on the fly. That's likely not going to be of suitable quality for Fedora itself, but it should be good enough for COPR and potentially even Playground.
My question is whether it would be practical to do something similar with pyp2rpm. Bonus points if we can come up with a way to integrate it nicely with COPR, or even tidy up the implementation to the point where we can convince Clark to accept the feature as part of mock itself :)
Hi Nick,
I have created vague named issue[0] at pyp2rpm repo we can discuss it there. I will post my opinion later, next week probably, currently I am off from work.
I like this idea. Not only it can be beneficial for people creating a whole environment for their Python application, but we would also be able to get a huge feedback on pyp2rpm and would be able to improve it significantly, I'd say. /me is wondering whether we could automatically generate SCLs by this, so that the packages wouldn't conflict with system ones. In the best case, one could even be able to do "mock-or-a-mock-wrapper --create-scl-from-this-app-and-build-it-in-copr /path/to/my/app scl_name" (I admit that naming command line arguments isn't my strongest skill...)
Slavek
Regards, Nick.
-- Nick Coghlan Red Hat Hosted & Shared Services Software Engineering & Development, Brisbane
HSS Provisioning Architect _______________________________________________ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Regards,
Robert Kuska
rkuska @ #fedora-devel on freenode #brno #gulag #software-collections on brq.redhat
[0] https://bitbucket.org/bkabrda/pyp2rpm/issue/13 _______________________________________________ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Dne 21.8.2014 09:40, Bohuslav Kabrda napsal(a):
I like this idea. Not only it can be beneficial for people creating a whole environment for their Python application, but we would also be able to get a huge feedback on pyp2rpm and would be able to improve it significantly, I'd say. /me is wondering whether we could automatically generate SCLs by this, so that the packages wouldn't conflict with system ones. In the best case, one could even be able to do "mock-or-a-mock-wrapper --create-scl-from-this-app-and-build-it-in-copr /path/to/my/app scl_name" (I admit that naming command line arguments isn't my strongest skill...)
Might also be usable for packagers trying to build something against the Python 3.5 SCL [1].
[1] http://copr.fedoraproject.org/coprs/churchyard/python3-nightly/
On 08/22/2014 05:52 AM, Miro Hrončok wrote:
Dne 21.8.2014 09:40, Bohuslav Kabrda napsal(a):
I like this idea. Not only it can be beneficial for people creating a whole environment for their Python application, but we would also be able to get a huge feedback on pyp2rpm and would be able to improve it significantly, I'd say. /me is wondering whether we could automatically generate SCLs by this, so that the packages wouldn't conflict with system ones. In the best case, one could even be able to do "mock-or-a-mock-wrapper --create-scl-from-this-app-and-build-it-in-copr /path/to/my/app scl_name" (I admit that naming command line arguments isn't my strongest skill...)
Might also be usable for packagers trying to build something against the Python 3.5 SCL [1].
[1] http://copr.fedoraproject.org/coprs/churchyard/python3-nightly/
Oh, I hadn't even thought of that, but yes, rebuilding for an SCL could be very cool. The "How do we rebuild/repackage our dependencies?" was actually one of the problems we ran into when considering using SCLs rather than putting up with running in an older version of Python.
Cheers, Nick.
python-devel@lists.fedoraproject.org
-
Bohuslav Kabrda -
Miro Hrončok -
Nick Coghlan -
Robert Kuska