3 ms·

I hate this shit. yaml -> pip install pyyaml cv2 -> pip install opencv-contrib-python PIL -> pip install pillow (wtf, this should be a misdemeanor

• cozzyd 2y ago
  Unless something is a binding, baking a package after the programming language is super weird. Like what if you change the implementation language later?
  • rty32 2y ago
    > what if you change the implementation language later? I don't think that is a thing that happens in real life. * Practically, one package is associated with exactly one github repository, sometimes a few. You would see implementation switching from JavaScript to TypeScript, but almost never from python to Go. Normally people start a brand new project for that kind of thing. * The reality is that each language has its own library ecosystem, and people reinvent the wheel at least once for each language. I wish we live in a world where you could save the effort, instead implement everything only once and it runs efficiently and has idiomatic APIs everywhere. But that's not how it works. If you create a package for a language, that's it. You could reimplement the same thing like by line in another language, but that would be a different package for that language.
    • cozzyd 2y ago
      It's pretty common for e.g. old scientific software to get rewritten from Fortran to C++ with a version bump.
    • dheera 2y ago
      Yeah but what is common in real life is writing multiple parallel libraries for {Python, NodeJS, ...} with a nearly identical API. In this case I would think that if the Python command is `pip install foo`, the NodeJS command should be `npm install foo`. It's redundant to do `pip install foo-python` when pip is only for Python, and opens the door for stealthy attacks where someone else creates `pip install foo` on PyPI that is forked from your repo and mirrors your API exactly but steals data and credentials and sends it to malicious servers.
      • kortex 2y ago
        > when pip is only for Python That's the neat part, it's not! You can distribute basically any kind of data with pip, within reason. Iirc Cmake can be pip-installed.
        • rented_mule 2y ago
          `pip install nodejs-bin` gets you node, including npm, in your venv along with bindings for calling it all from Python.
• nilamo 2y ago
  Pillow is a special case, in that it was always meant as a drop in replacement for the PIL, and you only changed the requirements.txt
  • ziml77 2y ago
    Feels to me like that was a deficiency in the package management tools. Like if your requirements file could define a global alias, it would allow people who want that easy one-line change to install pillow as PIL. But everyone else who was starting fresh or who was okay with doing a few edits to their Python files could install pillow and use it as pillow. I guess though that there could be an issue with some dependencies being written against PIL and others being written against pillow?
• woodruffw 2y ago
  Banning "py" would catch "mypy" and "pydantic", both of which you probably don't intend to catch. pillow is imported as `PIL` because it's a fork of the original PIL[1]. There's a very strong argument that Python's ability to retain the same import name across package name changes like that is a valuable source of flexibility that has benefited the ecosystem as a whole. [1]: https://pypi.org/project/PIL/ https://pypi.org/project/PIL/
  • throw-the-towel 2y ago
    > Python's ability to retain the same import name across package name changes... As in, `import pillow as PIL`?
    • woodruffw 2y ago
      > As in, `import pillow as PIL`? As in, not changing your imports at all, and just changing your dependency from PIL to pillow. This has two substantial advantages: 1. You only have to change one line (the dependency), not an indefinite number of source files. This is less of an issue now that the Python community has high-quality refactoring tools, but it's still the past of least resistance. 2. More importantly: `import pillow as PIL` is not referentially transparent: the `PIL` binding that it introduces is a `module` object, but that object can't be used in subsequent imports. In other words, blindly performing an `import X as Y` refactor would break code like this: import PIL from PIL import whatever You can observe this for yourself locally: >>> import ssl as lol >>> from lol import CERT_NONE ModuleNotFoundError: No module named 'lol' >>> from ssl import CERT_NONE This is arguably a defect in Python's import and module machinery, but that's how it currently is. Renaming the dependency and keeping the module name is far less fraught.
      • dheera 2y ago
        The related thing that bothers me deeply is that import PIL does not make PIL.Image available. What the hell else do you expect me to do with PIL? Why isn't PIL.Image included in importing PIL? You have to explicitly do either of these import PIL.Image from PIL import Image
• ziml77 2y ago
  I have to look up PIL every time I use it to remember if I install PIL and import pillow or install pillow and import PIL. Imports can be aliased, so why allow this mismatch at all? PyPI should have enforced that each package contains one top-level module whose name is identical to the name used to install it.
  • woodruffw 2y ago
    Imports can be aliased as bindings; they can't be aliased at the import machinery layer, which makes the PIL/pillow distinction necessary. The adjacent subthread has an example of this.
  • cqqxo4zV46cp 2y ago
    Starting any sentence in 2024 with “PyPI should have…” is a pretty ridiculous premise. We learn things over time, and PyPI itself wasn’t exactly operating on a green field.
  • remram 2y ago
    There used to be a PIL, someone made a new compatible distribution. They had to use the same import name to be compatible with existing code, they had to pick another name on PyPI that wasn't taken. It's kind of an extreme case.
• RockRobotRock 2y ago
  It's funny and sad how you remember the stupid aliases after a while.