Maybe this is better ?
.. python
import sys, os sys.path.insert(0, os.path.join(os.path.dirname(__file__), 'pagure')) from constants import __version__
This looks, in my opinion ugly in general. You should not try to parse python files manually.
Did you ever consider something like pkg_resources.get_distribution("pagure").version in the rest of the code, and just have setup.py be the authorative version information source?
Yes but I am not fan of having the version in the setup.py, for some reason the pkg_resources approach still makes me a little chilly
Well, manual python file parsing makes me very "chilly". And you even already import pkg_resources, so it wouldn't add another import.
If it were a different version.txt or something it'd be acceptable, but I really do not like manual python source file parsing for info like this..
Tbh, as the code comes from sqlalchemy, I'm not to chilly about this though I agree that it's far from ideal.
Fwiw, I like @puiterwijk's approach and try to use it (using pkg_resources.get_distribution("pagure")).
pkg_resources.get_distribution("pagure")
If that's not acceptable, I also like @mgautier's approach better than applying a regex to python source files.
I most of the time do not have pagure installed on the system, so how would pkg_resources work then?
With pkg_resources running pagure from a git checkout no longer works because we then run into:
pkg_resources.DistributionNotFound: pagure
for good reasons, pagure isn't installed nor built, so that makes sense to not find it.
Parsing the __init__.py might not be elegant but it is robust.
__init__.py
Invoking python setup.py build before the runserver does fix the error, but it does add an extra step and make things more complicated for new comers (imho).
python setup.py build
This is a matter of preference, so whichever way you want to go pingou, I think you have rights to go there.
There's no performance, security, scalability problem - the opening and regexing of the python file happens at build time in setup.py.
I think patrick and I don't like it because it seems like it could be someday fragile. If something changed about the version that didn't allow it to be parsed this way. If you depend on python's own versioning stuff, there's a lower likelihood that that would be the case. That stuff is built to handle versions. You're cooking your own here.
If this was in a core feature of pagure or something like that, I'd object more strongly.. but again, this is only at build-time. It's no big deal. If pingou prefers to keep his canonical copy of the version string in pagure/__init__.py, that's not something for us to block over.
pagure/__init__.py
Thanks @ralph, then I think I'll go with this approach and we can always revisit if that leads to problems in the future.