Greg Roodt

> each requesting a different set of versions of dependencies, it's up to the module extenison to decide what to do The third-party dependencies in rules_python are repositories, they're not...

Thanks for the details. It really seems like the real issue is this: `Our want is that we want the main repo to be able to import python files from...

> My original thought was that the solution would be to not special-case pip, but instead the pip module extension would generate a repository @@rules_python~~pip~pydantic which would then be visible...

> I don't think exposing the source as a package is a good long-term solution. Any solution other than just adding the py_library target as a dep and then importing...

I've been keeping an eye on this too. It will likely be easier for Python when Licensing is standardized in [PEP 639](https://peps.python.org/pep-0639/). It will support SPDX expressions as part of...

> From what groodt said, it sounds like hard part will be getting the license info from whatever artifact was downloaded from pypi? Yes. It's quite messy at the moment....

Ah, got it. Is there an example from other rules? My understanding of purl spec is that you can easily build it from the discrete components. pkg:pypi/[email protected] https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst It's unclear...

Is the prefix for python packages always `pkg:pypi/`? It seems the only necessary metadata to be added here are name and version? Is py_library the appropriate place for the metadata?...

Might be worth waiting for pip 25.1 ETA this weekend

Pip 25.1 was released https://pip.pypa.io/en/stable/news/#v25-1 So when the time comes to bump, we should aim for 25.1+ @aignas id correct that there are often quite a lot of bumpy regressions...