[16:59:35] <d0c_s4vage> before I start uploading random pypi packages to figure this out, are there any rules about names of distributions?
[17:00:00] <d0c_s4vage> as in, would someone be able to upload a distribution named "blah" if a distribution already existed named "Blah"?
[17:01:35] <dstufft> d0c_s4vage: there are rules yes
[17:01:46] <dstufft> basically we normalize the names prior to checking for uniquness
[17:02:09] <dstufft> that normalization is uh, basically `re.sub(r"[-_.]+", "-", name).lower()`
[17:02:47] <dstufft> and the only allowed values in a PyPI name are alpha numeric ASCII, - _ and . and it must begin and end with an alphanumeric
[17:02:57] <d0c_s4vage> ah, that's great news. simplifies my life immensely. I'm on the verge of starting a project that concretely maps distribution <-> package names
[17:03:37] <d0c_s4vage> afaik the only way to 100% know what packages a distribution provides is to install it and see what's newly available. So... I might be installing all ~90k pypi packages in the next week or so (in a vm)
[17:04:45] <dstufft> d0c_s4vage: yea, well you'll never get 100% :) THat way will probably get you about as close as you reasonably can though.
[17:05:20] <dstufft> (can't get 100% because there's nothing stopping people from doing crazy things like using the random module to generate package names in their setup.py)
[17:05:57] <dstufft> luckily I Don't think that is very likely :)
[17:06:29] <dstufft> what's more likely might be additional things isntalled or not installed pased on Python version or OS version, but if you're only look at top level names I don't think that is very likely either
[17:06:39] <dstufft> that's typically more an internal to a top-levle name thing
[17:06:54] <d0c_s4vage> there's also different versions of the packages too
[17:07:12] <d0c_s4vage> first attempt at this will only do the latest version, second attempt I'll see if it's worth it to figure out previous versions
[17:08:30] <dstufft> Awesome :] You might try ``setup.y egg_info`` and checking the info inside of that, it may contain the info you need without needing to trigger a whole install
[17:08:47] <d0c_s4vage> (this all started b/c I was working on https://github.com/d0c-s4vage/pipless and auto-installing packages, but then realized that distribution names !== package names)
[17:09:01] <d0c_s4vage> hrmm, I thought that wasn't always reliable though?
[17:09:13] <d0c_s4vage> if that would work, it'd definitely be easier
[17:10:29] <dstufft> I forget if there is metadata in there that looks at that info or not, if there is it should be roughly as reliable as an actual install. The difference would be if someone implemented their own install sub command and didn't use the setup() kwargs
[17:14:05] <d0c_s4vage> yeah... I think numpy doesn't use the normal setup() stuff. That was one of the examples that pointed me more towards directly installing everything
[17:16:36] <dstufft> If there are wheels available you can also download them and inspect inside them directly
[17:16:47] <dstufft> no need to run setup.py at all then
[17:16:55] <d0c_s4vage> that's a good point too. forgot about that one
[17:17:48] <d0c_s4vage> btw, with your comment here from yesterday: https://github.com/pypa/pip/issues/2432#issuecomment-247121434 - that sounds like an interesting feature. I might give it a go