If pyp2rpm generated this spec, it would work for Fedora as well as for epel7 so I would try to ask pyp2rpm guys if they can make the templates as unified as possible. I think that would benefit us all, really.

The other options are to use make_srpm method as a proxy (or now praiskup prepares custom method which would be probably more suitable for this case because you could just input pyp2rpm -t epel7 ... into a script field). Or we can add additional select field to pyp2rpm source type for the template selection (slightly tricky but also possible).

If pyp2rpm generated this spec, it would work for Fedora as well as for epel7 so I would try to ask pyp2rpm guys if they can make the templates as unified as possible. I think that would benefit us all, really.

They could also just update the Fedora template to more "generic" in a sense that it will work on other Distros as well (at least for epel7, this seems to be possible).

If pyp2rpm generated this spec, it would work for Fedora as well as for epel7

I'm not computing this statement. Clearly it didn't work for epel7 as the build log reported and clearly pyp2rpm-3.2.2 created it as the spec reports.

so I would try to ask pyp2rpm guys if they can make the templates as unified as possible. I think that would benefit us all, really.

But the problem is that the platforms are not unified. Fedora has %python_provide and Fedora packaging guidelines require (or request at least) that it be used. EL7 doesn't have this macro (AFAIK) so how can a unified specfile be made? I tend to think that this kind of disjointedness is exactly why there are templates that can be chosen from depending your your target platform.

So what is the problem with using the templates for the target chroot? I would imagine each type of chroot that Copr makes available has a suitable pyp2rpm template that can be associated with it.

The other options are to use make_srpm method

But I do I get the benefit of Anitya autobuild when I use make_srpm (or SCM) method? I don't think I do.

as a proxy (or now praiskup prepares custom method which would be probably more suitable for this case because you could just input pyp2rpm -t epel7 ... into a script field). Or we can add additional select field to pyp2rpm source type for the template selection (slightly tricky but also possible).

If pyp2rpm generated this spec, it would work for Fedora as well as for epel7

I'm not computing this statement. Clearly it didn't work for epel7 as the build log reported and clearly pyp2rpm-3.2.2 created it as the spec reports.

I was suggesting that we should try to open bug for this at pyp2rpm upstream so that it actually starts to work.

so I would try to ask pyp2rpm guys if they can make the templates as unified as possible. I think that would benefit us all, really.

But the problem is that the platforms are not unified. Fedora has %python_provide and Fedora packaging guidelines require (or request at least) that it be used. EL7 doesn't have this macro (AFAIK) so how can a unified specfile be made? I tend to think that this kind of disjointedness is exactly why there are templates that can be chosen from depending your your target platform.

EPEL7 does have %python_provide. The problem with EPEL is that it prefixes the python3 packages python34-, instead of python3- as Fedora (which can be fixed in the spec by using %{python3_pkgversion}. I don't think there is any other difference that would prevent the auto-generated specs for Fedora to work on EPEL7. In fact, that spec also works on Mageia (at least the package successfully builds there). Maybe we could just ask pyp2rpm guys to have an option to generate specs that simply work everywhere (at least inside COPR ecosystem, which means mageia+EPEL7+Fedora). This for sure is possible and quite desirable because with pyp2rpm you might be looking not only for generating nice specs that you can then use for an official Fedora package afterwards but also just for quick&dirty continuous integration with PyPI.

So what is the problem with using the templates for the target chroot? I would imagine each type of chroot that Copr makes available has a suitable pyp2rpm template that can be associated with it.

We could do that but instead we decided to provide means to enable user to tailor the srpm generation according his/her needs (make_srpm + upcoming custom method). It offers lots of freedom at price of slightly increased learning curve.

The other options are to use make_srpm method

But I do I get the benefit of Anitya autobuild when I use make_srpm (or SCM) method? I don't think I do.

Yes, that's true. But enabling anitya for SCM (and possibly also the upcoming Custom method) is something that we could do in future (it will require to extend auto-rebuild settings, which shouldn't be too much of a problem). I think it might be very useful, given the number of things that Anitya can track.

as a proxy (or now praiskup prepares custom method which would be probably more suitable for this case because you could just input pyp2rpm -t epel7 ... into a script field). Or we can add additional select field to pyp2rpm source type for the template selection (slightly tricky but also possible).

This ticket over at pyp2rpm is offering up templates as the solution to this problem.

Can you and the developers over there please get together and agree on which solution is going to be used to resolve this issue?

If a solution cannot be agreed on then IMHO, you may as well just remove the PyPI build option from Copr because it's just never going to work and PyPI-building priority needs to be refocused on enabling anitya for SCM.

So, the aforementioned ticket really seems to indicate that the pyp2rpm folks are not at all interested in making the fedora template work on EPEL7.

So in that light, can we move forwards on associating pyp2rpm templates with copr chroots so that pyp2rpm actually builds specfiles that will work on the chroot?

So, the aforementioned ticket really seems to indicate that the pyp2rpm folks are not at all interested in making the fedora template work on EPEL7.
So in that light, can we move forwards on associating pyp2rpm templates with copr chroots so that pyp2rpm actually builds specfiles that will work on the chroot?

I think you are misreading the comments in that issue.

So, the aforementioned ticket really seems to indicate that the pyp2rpm folks are not at all interested in making the fedora template work on EPEL7.
So in that light, can we move forwards on associating pyp2rpm templates with copr chroots so that pyp2rpm actually builds specfiles that will work on the chroot?

I think you are misreading the comments in that issue.

It's actually on a good way. If we have some kind of 'compat' template for generating .specs in pyp2rpm, we can then easily use it in COPR.

I think you are misreading the comments in that issue.

What is your interpretation?

It's actually on a good way. If we have some kind of 'compat' template for generating .specs in pyp2rpm, we can then easily use it in COPR.

Sure. I don't disagree. I don't a warm fuzzy feeling that the pyp2rpm maintainers will be developing and maintaining that template though. I have asked for clarification on that.

If they are expecting an external contribution and ongoing maintenance is that something this project is willing to do?

No response to my previous questions.

Can we make any progress here? With this impasse between Copr and pyp2rpm, the PyPI source model of Copr is pretty useless IMHO.

I'd go so far as to suggest that if this impasse is not going to be resolved one way or the other then the PyPI source be removed even.

No response to my previous questions.
Can we make any progress here? With this impasse between Copr and pyp2rpm, the PyPI source model of Copr is pretty useless IMHO.
I'd go so far as to suggest that if this impasse is not going to be resolved one way or the other then the PyPI source be removed even.

Well, we have this in our TODO list. I will make it a priority.

Ahhh. This is good. That it's at least on the TODO list is good to know.

It was just unclear up to this point where ownership of this was landing.

Fixed by https://pagure.io/copr/copr/c/47dff6d34668d96097ef7d2e4a0e633b6b28dcf5?branch=master

Sorry for the long wait.