3 ms·

> Do you want a free-for-all, or do you want curation and quality? Based on my experience, people prefer a free-for-all over distributions with outdated and/or

by dalke 4y ago

> Do you want a free-for-all, or do you want curation and quality? Based on my experience, people prefer a free-for-all over distributions with outdated and/or missing packages. I write packages for cheminformatics, which is mix of CS and chemistry. There are very few people who can curate in this field - far more than the number of producers. But there are some, like Debichem for Debian. Debichem distributed two of my packages. One was years out of date, and despite repeated attempts to inform them about newer versions, I never heard back from them. Instead, Debian users downloaded it from PyPI. The other was, oddly, a package that was published on my web site - not PyPI - for external feedback, before being integrated into the RDKit (a much larger package in my field). It wasn't meant for general distribution like through Debian, and only years later did I find out. No other package distributor has picked up my work. > I think the bare minimum requirement for all companies should be that they must host their own package repository, and 2 people must sign off on adding a package You and I live in far different computing environments. My customers include academics and single researchers in a non-IT-savvy company. And "prod" may start and end with "works for me, that's all I care about."

0xbadcafebee 4y ago
The way Linux distributions typically deal with that, is you host your packages on your own repository, provide your users instructions on how to add that repository, and have them install your packages from it. That's how big vendors keep their users' packages up to date, or keep from having to maintain multiple distros' packages (ex: ship one Debian package in your own repo that works on all Debian-esque distros). A compromise would be that new projects added to PyPI go through a vetting system, and a package maintainer's signing key gets added. Then they can push updated builds as much as they want, as long as it's signed by the maintainer. Less secure than distro-maintained packages, but it prevents typosquatting and simpler attacks on package integrity.
- dalke 4y ago
  > That's how big vendors keep their users' packages up to date What do small vendors, single developers, and hobbyists do? I don't even supply wheels for Microsoft Windows since that's not worth the difficulty. I can't imagine supporting {py3.8, 3.9, 3.10, 3.11} x {deb, rpm, whatever}, and providing installation instructions for the different platforms. For what it's worth, I do host my packages myself, and tell people to: python -m pip install chemfp -i https://chemfp.com/packages/ Luckily, I also have a safety net. I have an old (Python 2.7-only) distribution on PyPI. Even with the instructions, people will do "pip install chemfp" (without the "-i" index URL) and end up installing from PyPI. This then fails, so they either contact me, or read the instructions, or give up. > A compromise would be that new projects added to PyPI go through a vetting system Who will do that? Who will adjudicate conflicts? Who pays for their time? As I understand it, the PyPI maintainers are already pretty busy. I also pointed out how Debichem, a volunteer vetting system for chemistry packages for Debian, aren't able to provide timely vetting. > but it prevents typosquatting and simpler attacks on package integrity. How would it prevent typosquatting? What prevents someone from setting up "chamfp"?

by dalke 4y ago

0xbadcafebee 4y ago

The way Linux distributions typically deal with that, is you host your packages on your own repository, provide your users instructions on how to add that repository, and have them install your packages from it. That's how big vendors keep their users' packages up to date, or keep from having to maintain multiple distros' packages (ex: ship one Debian package in your own repo that works on all Debian-esque distros). A compromise would be that new projects added to PyPI go through a vetting system, and a package maintainer's signing key gets added. Then they can push updated builds as much as they want, as long as it's signed by the maintainer. Less secure than distro-maintained packages, but it prevents typosquatting and simpler attacks on package integrity.

dalke 4y ago
> That's how big vendors keep their users' packages up to date What do small vendors, single developers, and hobbyists do? I don't even supply wheels for Microsoft Windows since that's not worth the difficulty. I can't imagine supporting {py3.8, 3.9, 3.10, 3.11} x {deb, rpm, whatever}, and providing installation instructions for the different platforms. For what it's worth, I do host my packages myself, and tell people to: python -m pip install chemfp -i https://chemfp.com/packages/ Luckily, I also have a safety net. I have an old (Python 2.7-only) distribution on PyPI. Even with the instructions, people will do "pip install chemfp" (without the "-i" index URL) and end up installing from PyPI. This then fails, so they either contact me, or read the instructions, or give up. > A compromise would be that new projects added to PyPI go through a vetting system Who will do that? Who will adjudicate conflicts? Who pays for their time? As I understand it, the PyPI maintainers are already pretty busy. I also pointed out how Debichem, a volunteer vetting system for chemistry packages for Debian, aren't able to provide timely vetting. > but it prevents typosquatting and simpler attacks on package integrity. How would it prevent typosquatting? What prevents someone from setting up "chamfp"?