3 ms·
I'm really confused here. Are you really advocating that PyPi performs some kind of magic on the thousands and thousands of packages that are uploaded to ensure
by orf 11y ago
I'm really confused here. Are you really advocating that PyPi performs some kind of magic on the thousands and thousands of packages that are uploaded to ensure that all their unit tests pass, including testing the type annotations? Can you please give me an example of another languages packaging site with a non-trivial amount of packages that does this, or at least explain why this isn't the developers responsibility?
All you seem to be saying is that "Code should be tested before being uploaded to PyPi", and somehow that equates to type annotations being bad? Again, it's up to the developer to ensure his tests pass (by using a ci, or running tests locally, or even making a blood sacrifice to Cthulhu), and yes this should include a linter to ensure type annotations are correct if they are using them.
- lmm 11y ago> I'm really confused here. Are you really advocating that PyPi performs some kind of magic on the thousands and thousands of packages that are uploaded to ensure that all their unit tests pass, including testing the type annotations? I'm saying that the build tool should run unit tests and check annotations before uploading a package to PyPI. It doesn't matter whether checking annotations is done by a "compiler" or some other tool, but it does matter that whatever tool that is runs as part of the language standard release process (and in practice it tends to be the case that when a compiler enforces types then this happens, and when an external tool does then it doesn't). > it's up to the developer to ensure his tests pass (by using a ci, or running tests locally, or even making a blood sacrifice to Cthulhu) Leaving it up to the developer is a recipe for it not happening. We're programmers, we should automate these things.
- orf 11y ago> I'm saying that the build tool should run unit tests Building in Python is little more than creating a .tar.gz (or other format) of your source directory. Testing is very different and is very specific per project. Anyway, this whole discussion is pointless, you just need to run 'python setup.py test' before you run 'python setup.py bdist'. Is that so hard? If you really want you can edit your setup.py to do this first.
- lmm 11y agoI can edit my setup.py but I can't edit everyone else's. Defaults matter. My experience is that the average quality of random PyPI package is... not great, and I can't help thinking the anemic state of python build/project tooling is partly to blame.
- ubernostrum 11y agoThe tooling is fine for that kind of stuff. In fact there's an almost embarrassing number of different ways to do what you want (you can use your own local build/test/release, probably scripted with tox and other tools, or you can have Travis CI do it for you automatically, or...). I personally take a sort of halfway approach: I use Travis heavily for public documentation of the fact that my packages are fully tested and passing, but stop short of having it automatically release to PyPI for me when I tag a new version. But in general, the tools can't fix the fact that PyPI is not heavily curated. Any non-curated package repository will have the issues you're complaining about, even if the tools default to doing what you want them to do.
- lmm 11y agoMaybe. Maven Central isn't really curated, but by being associated with maven it encourages packages to run tests as part of the release process, and also to follow some standards in terms of e.g. package metadata pointing to the source repository and release tag in a standard format.