Fixing version scheme for PyPI. #160
Conversation
A dev release was published to PyPI as v1.0.0 back in 2012, making pip prioritize it over newer releases (with new features). After the next PyPI upload, `pip install autoenv` and `pip install -U autoenv` will both work as expected. This is not ideal semantic versioning, but it follows the rules.
|
Just checking back to see if there was any thoughts on this from the maintainers. When I first submitted the PR, GitHub flagged my account as a bot due to prior inactivity (made it months ago, but this is my first contribution), so I would not be surprised if the notifications for this PR got piped to devnull. |
|
+1 on this. I installed via pip per the README, and was confused as to why .env.leave was not working. I couldn't understand why my version didn't have LEAVE capability even though it was 1.0.0, but github code had it and said the project was 0.2.0. |
|
@rothwerx - your update on here made me realize that I had a typo of my own in my original post. (Whoops.) If you specify autoenv==0.2 on the pip command line, you'll get the newer version. I ended up having people install it directly from this git repo with pip. Works well enough. There's also the direnv project which is more actively maintained and might fit your needs. It's specifically for setting environment variables, so it should work for things like Python virtualenvs (since they're just munging your PATH, etc.), but won't work if you use your .env file for defining functions (the way I do). |
There's a PyPI package for autoenv marked as v1.0.0, back from 2012.
Since
piplooks for the latest package by version number rather than date, this makes a very old version of autenv the default. It's possible to get the newer code withpip install autoenv==0.2, but that's unintuitive**, and even moreso if you're updating from v1.0I'm proposing to kick the version up to v2.0, so that pip will work as expected, while keeping the version in line with SemVer principals. I understand there's still ongoing development here, but the interface is probably consistent enough that it won't rapidly shoot up to v42.0 or anything crazy like that. And if it does so what?
In any case, thanks for your work on this. It's a nifty little tool.
** Particularly for my Python-novice coworkers, who I'm pushing on to autoenv in order to standardize the use of virtual environments. Honestly, they'll need the latest updates from master, since I make use of AUTOENV_CUR_DIR (and the quotation fix, #150) in the .env script, but that will be published with this, sort of by definition. I'm hoping it isn't too long until that happens.
To wit: I had originally typed "==2.0" in this comment, and didn't realize until some eight months later, because using "==0.2" to get the latest code really is unintuitive. My apologies to anyone I accidentally misled with that typo!