Comment by dalke | Hacker News Reader

Comment by dalke | Hacker News Reader

Parent Full thread

I also don't have a smart phone or hardware key, and feel the same.

I host my packages on my own server using the PEP 503 "Simple Repository API". (For what it's worth, Donald Stufft, author of this PyPI blog post, also wrote PEP 503.)

I migrated away from PyPI years ago because modern FOSS distribution is increasingly intermediated by package managers, which I think worsens the connection between user and producer by adding a layer of anonymity.

I see 2FA as a technical work-around using mechanical trust instead of personal trust.

I don't care if people who don't know about me or my project web site can't find it on PyPI, because care is reciprocal - I want them to care about me too, at least enough to know where the project came from. That's where I think trust comes from.

My packages will never be popular. I develop very specialized software for a field with perhaps 10,000 world-wide users. No one will pay for my software, or hire my services, if they only visit PyPI.

I thankfully still have a Python 2.7 version of my software on PyPI. I haven't deleted it, to make name-squatting harder. It's even lead people to contact me directly, to ask about Python 3 support. I never would have heard from them, had I published the newest versions on PyPI, and that direct contact breaks the anonymity PyPI interposes.

A nice plus is how hosting means I have full access to the download logs, giving me insight onto what platforms people use that PyPI doesn't provide, because "anonymity".

The biggest annoyance is they main reason I started using PyPI was because someone else added another project of mine to PyPI.

I distributed https://pypi.org/project/PyRSS2Gen/ on my own web site as source. Someone else added it to PyPI, with me listed as the primary developer. I didn't know about it until the PyPI devs emailed developers like me to encourage them to support Python 3! I then had to ask that stranger for access to the PyPI entry.

I fear that will happen again, if I ever develop a new package that I distribute myself.

I hope this provide something for you to chew on, as you consider what you might do.

That's great!

While we strive to make PyPI useful for everyone we totally understand that sometimes the trade offs we have to make just don't work for everyone so we try really hard to enable folks like yourself to be able to set up their own repositories. I'm glad that it's working out for you and that you've got a setup you like.

I do want to mention two things:

We've got a PEP (PEP 708) going through the works that will tighten the security model around multiple repositories down some more. If I understand your uses well enough you should be able to add a line or two of HTML to your repository and not have any interruptions or warnings. That PEP isn't accepted yet or implemented or anything, but something to keep in the back of your mind at least.

While we don't make any sort of raw download logs available, we do publish what is essentially a query-able database of download events that have been parsed already to make it easy to see those stats. We do have a little bit of redaction on those events, primarily to avoid leaking PII like IP addresses and such, where instead of an IP address we log broad geographical area (country I think?).

If anyone is curious to see that, it's hosted in Google BigQuery (sorry, it does require a Google account) and there's a guide at https://packaging.python.org/en/latest/guides/analyzing-pypi... that tells you more about it.

Well, speak of the devil and he doth appear! :)

I looked at PEP 708. I was confused by what "repository" means. In PEP 503 "A repository that implements the simple API is defined by its base URL .... Within a repository, the root URL (/ for this PEP which represents the base URL) MUST be a valid HTML5 page with a single anchor element per project in the repository.".

A repository contains projects - "individual project contained within a repository".

PEP 708 seems to use "repository" to mean both that and individual project. Consider "To enable one repository to extend another, this PEP allows the extending repository to declare that it “tracks” another repository by adding the URL of the repository that it is extending."

The examples show project with new entries tracking a project on another repository.

This made it hard for me to understand what something like "repository owner" really means.

> If I understand your uses well enough you should be able to add a line or two of HTML to your repository and not have any interruptions or warnings.

I'm not sure it works, at least, not fully.

I tell people to use:

  python -m pip install chemfp -i https://chemfp.com/packages/

This used to contain only one project, "chemfp".

Now it also contains "click" and "tqdm" entries, copied verbatim from the respective PyPI project entries, because I recently added my first required install dependencies, and -i doesn't automatically fall back to PyPI.

I use '-i' because I don't want installs to start using the old chemfp version on PyPI. (Why? I only distribute pre-compiled wheels for 'manylinux'. I didn't release Python 3.11 wheels until a few weeks ago. I don't want pip for 3.11 users, or on macOS, to find the source version and try to install them. And "We’ve spent 15+ years educating users that the ordering of repositories being specified is not meaningful, and they effectively have an undefined order." ;)

I would prefer to not maintain copies of the click and tqdm project entries, as I need to remember to refresh them.

I think with PEP 708 I can have a single

    <meta name="pypi:alternate-locations" content="https://pypi.org/simple/click/">
    ...
    <body></body>

which will fix that pain point.

However, the main issue I have is namesquatting is still too easy. If I started chemfp now, with no PyPI entry, then from my side nothing changes.

But I've had people do "pip install chemfp" WITHOUT the -i option then ask what why it didn't work.

I assume that's because people aren't used to using a -i (or configuring it in their requirements.txt) so aren't sensitive as to why it's important.

Namesquatting a purely non-PyPI project then comes easy - register it on PyPI. PyPI is active about namesquatting, but you all surely don't track all small non-PyPI projects.

What I would like is, I thought, pretty simple:

    python -m pip install chemfp.com:/package/chemfp/

with the ability to also specify a path like that in the requirements.

That's considered in PEP 708 as possible ("To my knowledge the only systems that have managed to do this end up piggybacking off of the domain system and refer to packages by URLs with domains etc") but rejected ("our ability to retrofit that into our decades old system is practically zero without burning it all to the ground and starting over" ... "This would upend so many core assumptions ...")

This means while some of my current issues will be assuaged with this PEP, my fundamental concern will not.

Reply on news.ycombinator.com