Quote from @ilevkivskyi:
I have noticed that download numbers for mypy-lang grow over last month. I would say this indicates that there are new people who find some mentions (maybe in blogs or forums) of the old mypy-lang package and install it. <...>
Quote from @gvanrossum:
I think we should put a "tombstone" there that does nothing except print an error and exit 1. If we make it identical to the current release except for a warning that will just encourage people to keep using it, and then a few releases down the road it'll be out of date again.
Full discussion at https://github.com/python/mypy/issues/3885.
Let's make sure to make this a new major release, so it doesn't break things for anyone who does semver version pinning.
But what should the release number be? I take it that you think using e.g.
0.522 would not work, so it should be 1.0? But what would that do once the
real mypy 1.0 comes out? Or what exactly would be an example of semver
pinning?
The last mypy-lang release was 0.4.6, so I'd say if we bumped it to 0.5.0 that would handle it. Recall that we are talking about mypy-lang and not mypy, thus we are actually behind the current 0.521.
If we choose 0.5 that would allow people who currently set their dependencies to mypy-lang>0.4,<0.5 (get all patch updates in the 0.4.x series) to keep their current version (0.4.6) without breaking, but those who just put mypy-lang to get the latest, marker package (telling them to update).
Note in SemVer you are allowed to make backwards incompatible changes in minor releases if you are not 1.0 (since 1.0 specifies the public api and we haven't reached that yet).
Thanks, that makes perfect sense. Let's use 0.5.0.
Sounds good. Another thing to consider is how to announce this. We could either bundle this with another, normal mypy release, or create a separate blog post just for this. I'm leaning towards the latter.
Why do we need to announce it? We can just update the PyPI description.
(BTW could you make me an owner for the mypy-lang project on PyPI?)
Here's a proposed dummy that we can upload as mypy-lang 0.5.0:
https://github.com/gvanrossum/mypy-dummy
If the program does nothing but print an error, why not do it earlier? Perhaps instead of the console script approach, it just returns 1 from setup.py?
But does everyone who installs this go through setup.py?
Anyways, if you feel so inspired, go ahead and send a PR.
Thinking about it, personally I would probably waste more time debugging why the install fails than why the installed program fails. Installs tend to give copious output that obscures the crucial error (and they happen in CI during a generally verbose stage). But if you have an example of another project whose tombstone does this please show us!
I think I agree that the command line may lend itself to looking at the error. WRT not using setup.py, I just cannot think of a means of using mypy without setup.py based on an sdist on PyPI. I suppose you could download and untar the sources, but if the information is in the Description as well people will see it. But I suppose it is more robust to put it in a console script. I don't think my proposal adds anything significant.
@ethanhs Could you test https://github.com/gvanrossum/mypy-dummy on Windows? Jukka is planning to push this to PyPI next week, hopefully that will be the end of it.
Installing it without a previous mypy-lang works perfectly. I did run accross something however I don't think this is an issue with the package. If I python setup.py develop then it causes the console script to break. I believe this was an issue with the older console script method, so I believe this will work just as well as previous mypy-lang releases (if the above happens, the user has already encountered it).
Thanks for testing! That's good enough for me. Using setup.py develop
sounds like a good time to let users figure out they have to upgrade
anyways. :-)
I've uploaded a dummy mypy-lang 0.5.0 to PyPI.
I've uploaded a dummy mypy-lang 0.5.0 to PyPI.
Great! I will watch downloads stats and will report here in few weeks.
OK, so here are some updates on download stats:
mypy 64.9K downloadsmypy-lang 23.3K downloadsmypy 63.9K downloadsmypy-lang 34.6K downloadsAs you can see, the downloads for mypy-lang grew almost 50% while downloads for mypy didn't change. A possible explanation is that most people who have seen the "tombstone" just pinned their versions instead of moving to mypy as suggested.
If users decide to continue to use a pinned version of mypy-lang, it's probably fine since they should have received a note about the new package name. Download counts aren't really terribly informative since CI builds for a few big projects could account for a large fraction of the downloads, for example.
Do you have the numbers for how many downloads of mypy-lang were the
tombstone and how many were an actual release?
@gvanrossum This is actually a good question, here are three most popular downloads:
0.4.5: 27.5K0.4.6: 4.1K 聽0.5.0 (a.k.a. "tombstone"): 1.5K(other versions have 300 downloads/month or less).
Also 0.4.5 was released a year ago.
OK then I wouldn't worry about it too much. Somebody presumably has a CI
job pinned to 0.4.5 that downloads 0.4.5 every single time. As long as it's
not one of our friends at Facebook or Quora (who should know better) that's
their problem. I don't think it's our responsibility to remind them to
upgrade -- if they cared they would have.
We are safely on 0.530 :). And I'm pretty sure Facebook just runs mypy master.
Yes, we run master (upgraded approximately whenever we are motivated to get around to it). Definitely not downloading 0.4.5 for anything.
Most helpful comment
Let's make sure to make this a new major release, so it doesn't break things for anyone who does semver version pinning.