8 ms·

> A library with incorrect annotations in PyPI is extremely not-fine. As is a library with broken logic or one that throws exceptions randomly. You want Guido

• lmm 11y ago
  > As is a library with broken logic or one that throws exceptions randomly. You want Guido and the developers to implement some kind of system that automatically scans all PyPi packages for any kind of errors? Yes I do, but perfect is the enemy of good; it's ok to do something that makes things better without solving the whole problem. I want the build system to encourage people to do the right thing. E.g. any serious build system already ensures that you run the unit tests as part of the build or at least release process, because it would be just dumb to publish a library release on PyPI if it failed the unit tests. > I'm sure them solving the halting problem won't take that long. We already know how to avoid the halting problem, it's called types; see e.g. Idris. But you don't need to solve the halting problem to check annotations. It's not even hard. Why would you want to not check them? I mean if you're not even going to check them then why bother having annotations in the first place? Comments would provide the same functionality and have less danger of being misleading, because everyone already knows comments often end up being out of date.
  • 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 ago
          I 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 ago
            The 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.