| 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. |
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:
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
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:
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.