Hi @shaneallcroft , how is this going?

I've updated our Python spec template to match the latest guidelines so you could start from there. Please ping me on the channels if you run into issues:

https://pagure.io/neuro-sig/NeuroFedora/raw/main/f/spec-templates/python.spec

Thank you, will do -- I'll take care of this today :thumbsup:

@ankursinha Okay so I was able to get past the other issue with koji, but I'm now getting the error:

"'ERROR: Neither pyproject.toml nor setup.py found, consider using 
%pyproject_buildrequires -N <requirements-file> if this is not a Python
 package.'" 

I did some poking around in the source code and I think this error may be a symptom of a different problem -- AFAICT https://github.com/klim-/pyplane is written in python2. There is however, a more up to date python3 fork maintained by the original authors; https://github.com/TUD-RST/pyplane
It is currently in beta and comes with an additional known issue;
Under Linux the information dialog occuring when a new system is processed is not displayed completely sometimes
To me that sounds like it wouldn't be that much of a bother for most users, but I'm kind of in the dark as I don't have experience with the software.
What do you think, should I go ahead and package the TUD-RST fork instead?

What do you think, should I go ahead and package the TUD-RST fork instead?

I think you’ll have no choice—you certainly can’t package a version that doesn’t support Python 3.

+1, Python 2 is deprecated in Fedora so we don't include tools that don't support Python 3:

https://fedoraproject.org/wiki/Changes/RetirePython2

https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal

Is the fork actively maintained? I see the last commit from 2019 there which is already two years ago :(

https://github.com/TUD-RST/pyplane/commits/master

The develop branch seems active, but until they make a release, it's hard to say what the state of the tool is:

https://github.com/TUD-RST/pyplane/commits/develop

Have a look---if the tool doesn't look stable enough, we could leave it for the time being until upstream makes a release?

That makes sense, thanks all. I played around with it for a while and didn't encounter any issues. The information dialogue displayed consistently too, and didn't seem to contain any information that couldn't be found in the main gui anyway. I'll go ahead and package the develop version now. :thumbsup: :thumbsup:

Sounds good!

You can use the forge macros to make life a little easier:

https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_commit_example

Note that you'll have to set the appropriate release field depending on whether this is a pre-release snapshot etc.:

https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_snapshots_2

Those links helped ty -- I think I'm close, but currently dealing with an error during (%generate_build_requires) when I use the -t flag as per our template

ERROR: tox config file (either pyproject.toml, tox.ini, setup.cfg) not found

And when I try to run it without the -t flag it successfully builds and installs pyplane, but fails during (%check) citing a missing 'pytest' directory. I'll keep tinkering with it, just thought I might as well post the error just in case anyone else has dealt with this same issue :thumbsup: :thumbsup: :thumbsup:

https://gist.github.com/shaneallcroft/0cebe661ce9c6c9f61a3fa12bfc8f952
^^^ (current spec file for reference)

OK, sounds good. We can take a look at it later once it's complete---looks very good so far! Some notes:

• your release field will change according to the guidelines I noted above

• your summary will need to be shorter

• your description can be longer :P (I generally copy the long description from the Readme or the pypi project page)

• any reason why you are defining the python version to 3.8? We need to build against the default system version, which is now a python 3.10 RC in rawhide. if packages don't build against 3.10, we need to file bugs upstream to let them know (and if possible provide patches).

You should run rpmlint on your spec and srpm regularly, and that'll keep pointing out these minor issues. (use rpmlint -i to get more information on the outputs)

I'll incorporate that feedback pronto ty ty : )
Also good catch, I forgot I did that -- the develop repo specifies
"PyPlane is a free software for phase plane analysis of second order dynamical systems written for PYTHON 3.8..."
I added that line as a sanity check to troubleshoot a different error, but forgot to change it back,,, doing that now :/

I'll incorporate that feedback pronto ty ty : )
Also good catch, I forgot I did that -- the develop repo specifies
"PyPlane is a free software for phase plane analysis of second order dynamical systems written for PYTHON 3.8..."
I added that line as a sanity check to troubleshoot a different error, but forgot to change it back,,, doing that now :/

No worries. All of this will be checked in the review anyway. Since they specify 3.8 let's hope that it still runs fine with 3.10. If it does, we can let them know. If it doesn't, we can still file issues and maybe patches depending on what the errors are.

Once you have a spec and srpm that builds correctly, you can even run fedora-review locally to see what you get:

fedora-review -n <package name>

https://src.fedoraproject.org/rpms/fedora-review

https://paste.centos.org/view/707fb6ee
koji output

https://paste.centos.org/view/8ff90db0
spec file

Upstream imports pyplane.core as core after messing with sys.path in https://github.com/TUD-RST/pyplane/blob/master/tests/test_core.py#L4. This is weird and not so wonderful.

Try something like:

export PYTHONPATH='%{buildroot}%{python3_sitelib}:%{buildroot}%{python3_sitelib}/pyplane'
%pytest

and see if it works.

GOOD catch ty ty, thats gotta be the issue -- not so wonderful indeed. Where in the spec file should I put that export line? I tried putting directly before and directly after the %install, but am getting the same output as I just did. I'll try putting it just before build?

That should be part of the %check section; note the %pytest macro immediately following. The %pytest macro itself sets PYTHONPATH if it is unset, but will accept an override from the environment.

Note that exported environment variables are not carried from one section to another.

I will fool around with this more today, getting an issue with a missing matplotlib module now.
https://paste.centos.org/view/9be2dcf1

Is matplotlib installed as a BuildRequires (either manually or using the generate_buildrequires macro?)

Could you throw your spec into a Git repo somewhere so we could look at it and suggest tweaks please maybe? Either github or a new repo here on pagure works. I tend to create a new repo here for each new package (and delete the repo once the package has been included in Fedora).

Insofar as I can tell I did add it manually to the BuildRequires? But yeah for sure sounds good I'll make a repo now :thumbsup:

EDIT:
Okay here it is
https://pagure.io/neuro-sig/python-pyplane

Okay so from what I understand, I'm specifying matplotlib as a requirement in every available place in the spec file, but I'm still failing with 'status 30' from a missing matplotlib according to root.log. I feel like I might be messing something simple up, any obvious faults in my spec file?
https://pagure.io/neuro-sig/python-pyplane
thanks for help and patience all :thumbsup:

That's because the name of the package is not matplotlib. It's python3-matplotlib, or you can use the standardised form: %{py3_dist matplotlib}.

I'm looking at your spec now, will open a PR with some tweaks :)

PR opened at your repo now. They made a release a few days ago, so I've updated to use that etc.

Ahh, okay yeah that makes a lot of sense ty ty. Also didn't realize they made a release that's perfect

Okay everything checked out, I submitted a review with fedora-create-review and it seems to have worked :thumbsup: :thumbsup: Is there something I should do to follow up with the review?

Can you provide a link to the review? Someone from the team can then review it :clap:

@shaneallcroft : was the review correctly created? I can't seem to find it on bugzilla. It isn't listed on the review tracker pages either:

https://fedoraproject.org/PackageReviewStatus/