pyeve / eve-sqlalchemy

SQLAlchemy data layer for Eve-powered RESTful APIs
http://eve-sqlalchemy.readthedocs.io
Other
232 stars 70 forks source link

Update module version #81

Closed joystein closed 7 years ago

joystein commented 8 years ago

The version in the module differed from the one in setup.py. Also added bumpversion if that would be interesting.

dkellner commented 7 years ago

I know it's late to answer this pull request, but I just recently got the right to merge those. So let's get to work :).

I'm a bit opposed to introducing another dependency (bumpversion) for this - and Eve does not use it, as well. Although this is a separate project, I'd like to keep things "in sync", so developers will instantly feel home in both projects.

As far as I see know, we only have two files where we hardcode the version: eve_sqlalchemy/__init__.py and setup.py. Can we just include the former in the latter and reuse __version__? Or is that considered a bad practice? I'm not too familiar yet with the packaging / PyPI workflow, so any advice here is appreciated.

joystein commented 7 years ago

A developer dependency like bumpversion could be made optional by using extras_require. See for instance here:

For how versioning can be done, in particular single source versioning, see:

From the options listed in that document, i think options 2 and 3 looks the most palatable. From just looking at the eve project, it would seem that the versioning is managed outside of code, either by hand or an external tool. This should then favor option 2, which mentions bumpversion as one of the tools that can be used.

This is not extremely important issue for me, but i think that documenting the release procedure, preferably automating it with a build or task tool, would make it easier for others to help out with making releases. And, not to forget, make it easier to keep the versions in sync across the project.

Normally i would use pyinvoke to automate any manual work that needs to be done when releasing a package (never did this to pypi though, just private packages).

That said, i'm not sure its strictly necessary to have the version in the top-level module file. From reading this https://python-packaging-user-guide.readthedocs.io/distributing/#version, it seems it depends on the package.

dkellner commented 7 years ago

Thank you very much for outlining this and providing many great sources! I will read through this (hopefully this weekend) and will probably come back to you later to benefit from your experience. I agree that automating this process would be the most preferable solution.

dkellner commented 7 years ago

OK, I will need a few more days before merging this. Just want to let you know that your guidance was really helpful already and I'm currently delving deeply in the related documentation and fixing minor issues along the way. Expect another PR to discuss the changes by the end of the week.

joystein commented 7 years ago

I'm very glad to hear that my input could be of use. I must also say that so far you have been handling this project very well. Keep up the good work!

joystein commented 7 years ago

I guess this can be closed then with the addition of zest.releaser?