New release?

[flying-sheep]

Hi! I have a few 3.5+ packages relying on flit and future-fstrings. Using the dev version of flit is a bit cumbersome.

PS: If you find it to annoying to make releases, I recommend transitioning flit to get_version. It makes a new release as easy as git tag v1.2.3 && flit publish && git push --tags

[takluyver]

1.3 is on PyPI now.

Thanks, but I don't find updating the version number is a significant amount of the effort in creating a new release, and I don't like the notion of packages looking up their own metadata at import time in any case.

[flying-sheep]

Thank you so much!

I don't like the notion of packages looking up their own metadata at import time in any case.

Oh, why not? because there could be multiple versions of the same package installed?

In any case, it’s the only way to do it with flit having no build step!

[takluyver]

For much the same reason that I don't like objects inspecting the stack to find out what their name is in some namespace; it feels inside-out. Especially for something that happens on import, I don't want the package poking around my filesystem trying to find its metadata, or running git in a subprocess.

The problem it's solving also isn't something that bothers me much. Assembling a decent set of release notes takes much longer than changing a version number.

I do find it slightly inconvenient at times that the version number has to be set in multiple places. You can see in the commit history that I initially forgot to change the version number to 1.3 for the docs, and had to make another commit to do that. But for this I prefer the kind of approach offered by bumpversion, where the extra complexity is in developer tools, not something that happens at runtime in the module.

[flying-sheep]

Assembling a decent set of release notes takes much longer than changing a version number.

It’s true, however the state of the release notes on publication isn’t that important, since readthedocs/latest shows the release notes from the master branch. For my own projects, I usually prefer having bugfix releases out fast instead of waiting until I can take the time to update the release notes. Once I have the time, I go through the git history and retroactively compile the release notes.

[takluyver]

I like to do release notes when I'm making the release, because otherwise I'll probably never do them. 🙂

[flying-sheep]

I like to do release notes when I'm making the release, because otherwise I'll probably never do them. 🙂

I don’t know why I manage to not procrastinate in that regard while procastinating is so many others, but somehow it comes easily to me. Maybe because I enjoy reading release notes for projects I’m excited about (including this one, thank you for it!)

You can see in the commit history that I initially forgot to change the version number to 1.3 for the docs

Haha, that’s exactly what I wanted to avoid and why i wrote get_version. I assume everything I have to do manually will be forgotten, including calling things like bumpversion (then again it also creates the git tags, so retraining myself to it sounds possible 🤔).

For my R stuff I also regularly forget recompiling the docs. If I can integrate things like that into the build system, I’m happy. Flit doesn’t have a customizable build step, so I went the metadata route.

[takluyver]

projects I’m excited about (including this one, thank you for it!)

Thanks! 😃

I assume everything I have to do manually will be forgotten, including calling things like bumpversion

I'm not too worried about forgetting to increment the version number at all - that's an intrinsic part of what I think of as 'making a release'. And if I don't do it, the upload will fail anyway. But I do sometimes have trouble remembering the different places it needs updating.

Flit doesn’t have a customizable build step

The idea is still under consideration (#119), but it's not a priority at the moment. Part of what's so nice about Flit is the simplicity of not having a build step.

I did start a project called modeltee to automate release steps, as distinct from build steps. That includes things like tagging the release and publishing it to PyPI. I keep meaning to get back to working on it, to the point where I use it for projects like Flit.

[flying-sheep]

As soon as any kind of information is at two separate places in the same project, I consider that a bug in the tooling.

[takluyver]

I agree that it's good to have a 'single source of truth'. That's why Flit doesn't require the version number in the configuration. But I prefer a bit of duplication to some of the solutions to avoid it.

[flying-sheep]

Certainly. I think the my favourite solution would be get_version at development, and an AST modifying build step to dynamically replace __import__('get_version').get_version() with a version string.

Pros	Cons
Single truth	Complex AST-transform code
No _versioneer.py in VCS	Build step
No prod dependencies
Source of truth isn’t “backwards” in metadata

Using get_version as-is trades the build step and complexity for a runtime dependency in production and the “backwards” metadata source-of-truth.