| 1 |
On Sat, Jan 28, 2023 at 05:38:05PM +0100, Michał Górny wrote: |
| 2 |
> Hi, everyone. |
| 3 |
> |
| 4 |
> TL;DR: I'd like to propose naming dev-python/* packages following PyPI |
| 5 |
> names whenever possible, case-preserving, with modifications only when |
| 6 |
> necessary to match PN rules. |
| 7 |
> |
| 8 |
> |
| 9 |
> So far the naming in dev-python/* hasn't been exactly consistent. |
| 10 |
> Myself I've been mostly following "whatever's the easiest" policy which |
| 11 |
> generally meant following GitHub project names whenever we fetched from |
| 12 |
> there. |
| 13 |
> |
| 14 |
> This mostly made sense so far, as I've been thinking of dev-python/ |
| 15 |
> primarily in terms of dependencies of other packages. However, it's |
| 16 |
> been pointed out that this makes it hard for people to find packages |
| 17 |
> they're looking for. |
| 18 |
> |
| 19 |
> The vast majority of packages in dev-python/ are also published on PyPI |
| 20 |
> [1]. They can afterwards be installed using tools such as pip, or |
| 21 |
> specified as dependencies of other projects — using their PyPI names |
| 22 |
> in every case. |
| 23 |
> |
| 24 |
> On top of that, it is not unknown for multiple packages with very |
| 25 |
> similar names to coexis, say "foo", "pyfoo" and "python-foo". When GH |
| 26 |
> project names come into the picture, this can get even more ambiguous. |
| 27 |
> Don't even get me started about developers pushing duplicate packages |
| 28 |
> because they didn't find the existing instance. |
| 29 |
> |
| 30 |
> |
| 31 |
> To improve consistency and make packages easier to find, I'd like to |
| 32 |
> propose going forward that when packages are published on PyPI, we use |
| 33 |
> their official PyPI names. This also means preserving the case for |
| 34 |
> the few packages that use CamelCase names and similar. |
| 35 |
> |
| 36 |
> Some modifications will be necessary. For example, it is legal for PyPI |
| 37 |
> package names to include dot (".") — we normally translate that to a |
| 38 |
> hyphen ("-"). We may also have use cases for creating multiple Gentoo |
| 39 |
> packages from the same PyPI package (see e.g. dev-python/ensurepip-*). |
| 40 |
> Then, there are of course Python packages that aren't published on PyPI. |
| 41 |
> |
| 42 |
> Still, I think as a general rule of thumb this would make sense. WDYT? |
| 43 |
|
| 44 |
Just to say I'm all for it. As much as I don't like some of the |
| 45 |
pypi^H^H^H^HPyPi^HI names and mismatches from the "typical" style |
| 46 |
used in the tree, it's a small price to pay for consistency within |
| 47 |
this large group of packages. |
| 48 |
|
| 49 |
> |
| 50 |
> |
| 51 |
> [1] https://pypi.org/ |
| 52 |
|
| 53 |
-- |
| 54 |
ionen |
Archives