On Sat, 2023-01-28 at 17:38 +0100, Michał Górny wrote:

TL;DR: I'd like to propose naming dev-python/* packages following PyPI
names whenever possible, case-preserving, with modifications only when necessary to match PN rules.

Based on existing remote-id entries, the following package names are
mismatched (PN on left, PyPI name on right). Note that some of the IDs
could be wrong, particularly because PyPI "autocorrects" - vs _.



aiohttp-cors | aiohttp_cors
anyqt | AnyQt
automat | Automat
aws-xray-sdk-python | aws-xray-sdk
blake3-py | blake3
boolean-py | boolean.py
bottleneck | Bottleneck
cachecontrol | CacheControl
cangjie | CangJie
cerberus | Cerberus
certifi | certifi-system-store
chameleon | Chameleon
charset_normalizer | charset-normalizer
cheetah3 | Cheetah3
cherrypy | CherryPy
cjkwrap | CJKwrap
cli_helpers | cli-helpers
collective-checkdocs | collective.checkdocs
configupdater | ConfigUpdater
cx_Freeze | cx-Freeze
cython | Cython
deprecated | Deprecated
discogs-client | python3-discogs-client
django | Django
django_polymorphic | django-polymorphic
dogpile-cache | dogpile.cache
easyprocess | EasyProcess
editorconfig-core-py | EditorConfig
elasticsearch-py | elasticsearch7
ensurepip-pip | pip
ensurepip-setuptools | setuptools
ensurepip-wheels | pip
et_xmlfile | et-xmlfile
eyeD3 | eyed3
flask-api | Flask-API
flask-babel | Flask-Babel
flask-compress | Flask-Compress
flask-cors | Flask-Cors
flask-debug | Flask-Debug
flask-gravatar | Flask-Gravatar
flask-htmlmin | Flask-HTMLmin
flask-login | Flask-Login
flask | Flask
flask-migrate | Flask-Migrate
flask-paranoid | Flask-Paranoid
flask-script | Flask-Script
flask-sphinx-themes | Flask-Sphinx-Themes
flit_core | flit-core
flit_scm | flit-scm
flufl-lock | flufl.lock
genshi | Genshi
github3 | github3.py
gmpy | gmpy2
google-reauth-python | google-reauth
hcloud-python | hcloud
imapclient | IMAPClient
importlib_metadata | importlib-metadata
importlib_resources | importlib-resources
indexed_gzip | indexed-gzip
jack-client | JACK-Client
jaraco-classes | jaraco.classes
jaraco-collections | jaraco.collections
jaraco-context | jaraco.context
jaraco-envs | jaraco.envs
jaraco-functools | jaraco.functools
jaraco-itertools | jaraco.itertools
jaraco-logging | jaraco.logging
jaraco-path | jaraco.path
jaraco-stream | jaraco.stream
jaraco-test | jaraco.test
jaraco-text | jaraco.text
jinja | Jinja2
js2py | Js2Py
jschema_to_python | jschema-to-python
jupyter_client | jupyter-client
jupyter_console | jupyter-console
jupyter_core | jupyter-core
jupyter_events | jupyter-events
jupyter_kernel_test | jupyter-kernel-test
jupyterlab_pygments | jupyterlab-pygments
jupyterlab_server | jupyterlab-server
jupyter_packaging | jupyter-packaging jupyter_server_mathjax | jupyter-server-mathjax
jupyter_server | jupyter-server
keyrings-alt | keyrings.alt
keystoneauth | keystoneauth1
libcloud | apache-libcloud
libpillowfight | pypillowfight
libsass-python | libsass
line_profiler | line-profiler
logbook | Logbook
m2crypto | M2Crypto
mako | Mako
mapbox_earcut | mapbox-earcut
markdown | Markdown
markupsafe | MarkupSafe
markups | Markups
mdx_gh_links | mdx-gh-links
memory_profiler | memory-profiler
mergedict | configclass
minikanren | miniKanren
minimock | MiniMock
mkdocs_pymdownx_material_extra | mkdocs-pymdownx-material-extra mypy_extensions | mypy-extensions
myst_parser | myst-parser
nest_asyncio | nest-asyncio
netcdf4-python | netCDF4
notebook_shim | notebook-shim
octave_kernel | octave-kernel
oslo-concurrency | oslo.concurrency
oslo-config | oslo.config
oslo-context | oslo.context
oslo-i18n | oslo.i18n
oslo-log | oslo.log
oslo-serialization | oslo.serialization
oslo-utils | oslo.utils
owslib | OWSLib
pallets-sphinx-themes | Pallets-Sphinx-Themes
parse_type | parse-type
pastedeploy | PasteDeploy
paste | Paste
pebble | Pebble
pillow | Pillow
pkgcraft-python | pkgcraft
pmw | Pmw
podman-py | podman
pretty-yaml | pyaml
prometheus_client | prometheus-client
prompt_toolkit | prompt-toolkit
protobuf-python | protobuf
pure_eval | pure-eval
pushbullet-py | pushbullet.py
py-amqp | amqp
pyaudio | PyAudio
pychromecast | PyChromecast
pycson | cson
pygments-github-lexers | pygments-github-lexers
pygments | Pygments
pygobject | PyGObject
pygresql | PyGreSQL
pyhamcrest | PyHamcrest
pyicu | PyICU
pyjwt | PyJWT
pykerberos | kerberos
pylatex | PyLaTeX
pymysql | PyMySQL
pynacl | PyNaCl
pyopengl_accelerate | PyOpenGL-accelerate
pyopengl | PyOpenGL
pyopenssl | pyOpenSSL
pyproject-hooks | pyproject_hooks
pyre2 | fb-re2
pyrfc3339 | pyRFC3339
pyside2 | PySide2
pyside6 | PySide6
pysol_cards | pysol-cards
pysvg | pysvg-py3
pytables | tables
pytest-codeblocks | pytest_codeblocks
pytest_jupyter | pytest-jupyter
pytest-param-files | pytest_param_files
python-cstruct | cstruct
python-ctags | python-ctags3
pythondialog | python2-pythondialog
python-discid | discid
python-email-validator | email-validator
python-evdev | evdev
python-keyutils | keyutils
python-lhafile | lhafile
python-libevdev | libevdev
python-miniupnpc | miniupnpc
python-mpd | python-mpd2
python-musicbrainzngs | musicbrainzngs
python-nbxmpp | nbxmpp
python-netlink | NetLink
python-ptrace | pefile
python-recurring-ical-events | recurring-ical-events
python-sense-hat | sense-hat
python-sshpubkeys | sshpubkeys
python-varlink | varlink
python-xmlsec | xmlsec
python-zeroconf | zeroconf
python-zstandard | zstandard
pytrie | PyTrie
pytz_deprecation_shim | pytz-deprecation-shim
pyvirtualdisplay | PyVirtualDisplay
pywavelets | PyWavelets
pyx | PyX
pyyaml | PyYAML
qdarkstyle | QDarkStyle
qscintilla-python | QScintilla
qtawesome | QtAwesome
rapidfuzz_capi | rapidfuzz-capi
readme_renderer | readme-renderer
redis-py | redis
reedsolomon | reedsolo
repoze-lru | repoze.lru
requests-ntlm | requests_ntlm
routes | Routes
rpy | rpy2
rst-linker | rst.linker
rtimulib | RTIMULib
ruamel-std-pathlib | ruamel.std.pathlib
ruamel-yaml-clib | ruamel.yaml.clib
ruamel-yaml | ruamel.yaml
sarif_om | sarif-om
secretstorage | SecretStorage
semantic_version | semantic-version
send2trash | Send2Trash
service_identity | service-identity setuptools_scm_git_archive | setuptools-scm-git-archive setuptools_scm | setuptools-scm
signature_dispatch | signature-dispatch
snappy | python-snappy
socketio-client-nexus | socketIO-client-nexus sphinx-aiohttp-theme | aiohttp-theme
sphinx_ansible_theme | sphinx-ansible-theme sphinxcontrib-github-alt | sphinxcontrib_github_alt sphinxcontrib-log_cabinet | sphinxcontrib-log-cabinet sphinx_lv2_theme | sphinx-lv2-theme
sphinx | Sphinx
sphinx-py3doc-enhanced-theme | sphinx_py3doc_enhanced_theme sphinx-pytest | sphinx_pytest
sphinx_rtd_theme | sphinx-rtd-theme sphinx_selective_exclude | sphinx-selective-exclude
sqlalchemy | SQLAlchemy
stack_data | stack-data
stomp-py | stomp.py
subunit | python-subunit
svg-path | svg.path
swagger_spec_validator | swagger-spec-validator
tappy | tap.py
tlsh | python-tlsh
tubes | Tubes
twisted | Twisted
unidecode | Unidecode
uri_template | uri-template
urwid_readline | urwid-readline
utidylib | uTidylib
wand | Wand
webob | WebOb
webtest | WebTest
werkzeug | Werkzeug
whoosh | Whoosh
wsgiproxy2 | WSGIProxy2
wtforms | WTForms
wxpython | wxPython
xlsxwriter | XlsxWriter
yapsy | Yapsy
zc-lockfile | zc.lockfile
zconfig | ZConfig
zope-component | zope.component
zope-configuration | zope.configuration
zope-deprecation | zope.deprecation
zope-event | zope.event
zope-exceptions | zope.exceptions
zope-hookable | zope.hookable
zope-i18nmessageid | zope.i18nmessageid
zope-interface | zope.interface
zope-schema | zope.schema
zope-testing | zope.testing


--
Best regards,
Michał Górny

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi, everyone.

TL;DR: I'd like to propose naming dev-python/* packages following PyPI
names whenever possible, case-preserving, with modifications only when necessary to match PN rules.


So far the naming in dev-python/* hasn't been exactly consistent.
Myself I've been mostly following "whatever's the easiest" policy which generally meant following GitHub project names whenever we fetched from
there.

This mostly made sense so far, as I've been thinking of dev-python/
primarily in terms of dependencies of other packages. However, it's
been pointed out that this makes it hard for people to find packages
they're looking for.

The vast majority of packages in dev-python/ are also published on PyPI
[1]. They can afterwards be installed using tools such as pip, or
specified as dependencies of other projects — using their PyPI names
in every case.

On top of that, it is not unknown for multiple packages with very
similar names to coexis, say "foo", "pyfoo" and "python-foo". When GH
project names come into the picture, this can get even more ambiguous.
Don't even get me started about developers pushing duplicate packages
because they didn't find the existing instance.


To improve consistency and make packages easier to find, I'd like to
propose going forward that when packages are published on PyPI, we use
their official PyPI names. This also means preserving the case for
the few packages that use CamelCase names and similar.

Some modifications will be necessary. For example, it is legal for PyPI package names to include dot (".") — we normally translate that to a
hyphen ("-"). We may also have use cases for creating multiple Gentoo
packages from the same PyPI package (see e.g. dev-python/ensurepip-*).
Then, there are of course Python packages that aren't published on PyPI.

Still, I think as a general rule of thumb this would make sense. WDYT?


[1] https://pypi.org/

--
Best regards,
Michał Górny

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Jan 28, 2023 at 05:38:05PM +0100, Michał Górny wrote:

Hi, everyone.

TL;DR: I'd like to propose naming dev-python/* packages following PyPI
names whenever possible, case-preserving, with modifications only when necessary to match PN rules.

So far the naming in dev-python/* hasn't been exactly consistent.
Myself I've been mostly following "whatever's the easiest" policy which generally meant following GitHub project names whenever we fetched from there.

This mostly made sense so far, as I've been thinking of dev-python/
primarily in terms of dependencies of other packages. However, it's
been pointed out that this makes it hard for people to find packages
they're looking for.

The vast majority of packages in dev-python/ are also published on PyPI
[1]. They can afterwards be installed using tools such as pip, or
specified as dependencies of other projects — using their PyPI names
in every case.

On top of that, it is not unknown for multiple packages with very
similar names to coexis, say "foo", "pyfoo" and "python-foo". When GH project names come into the picture, this can get even more ambiguous.
Don't even get me started about developers pushing duplicate packages
because they didn't find the existing instance.

To improve consistency and make packages easier to find, I'd like to
propose going forward that when packages are published on PyPI, we use
their official PyPI names. This also means preserving the case for
the few packages that use CamelCase names and similar.

Some modifications will be necessary. For example, it is legal for PyPI package names to include dot (".") — we normally translate that to a
hyphen ("-"). We may also have use cases for creating multiple Gentoo packages from the same PyPI package (see e.g. dev-python/ensurepip-*).
Then, there are of course Python packages that aren't published on PyPI.

Still, I think as a general rule of thumb this would make sense. WDYT?

Just to say I'm all for it. As much as I don't like some of the pypi^H^H^H^HPyPi^HI names and mismatches from the "typical" style
used in the tree, it's a small price to pay for consistency within
this large group of packages.

[1] https://pypi.org/

--
ionen

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEx3SLh1HBoPy/yLVYskQGsLCsQzQFAmPVWl8ACgkQskQGsLCs QzQmhAf/Z1UpJ+Fp/Y8TRwWGJTVTJo46ACBD9f19voPmSfRlVSYksD6M+2K7p3fd S9uHeEKt9Qr3c7YG+DsYallXw5hA4k23yuKzjVNX+dW+7kkwnoayhjgBxOiX6LyD i0TEqP2ovm6atlt4AR8G6J4EKGyvnGEDRRYCw4iV3ToPSNabZ/CaEOIri9CIZ5Ti BGQ7RjjPN74YcPRcW2W72Y+66uRysg74updYh3/MDWkKvAx6zD1+tq/YYhhVg/DP h5RZPZpxsMp91nX0PD1nTehOKOKnoQavTKArSFSq6ApQQBz/O0qTM9PpJPlMEUI+ tVr5bTae/uD1UFzVwX9aTAI//EvCFA==
=LY2I
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 28 Jan 2023, Michał Górny wrote:

Based on existing remote-id entries, the following package names are mismatched (PN on left, PyPI name on right). Note that some of the IDs
could be wrong, particularly because PyPI "autocorrects" - vs _.

Are there any rules by which upstream use of upper vs lower case can be predicted? On first glance they look completely random, which is exactly
the reason why we have an all-lowercase policy for PN.

However, it's been pointed out that this makes it hard for people to
find packages they're looking for.

I don't understand this argument. Why would all-lowercase make finding a package harder?

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQFDBAEBCAAtFiEEtDnZ1O9xIP68rzDbUYgzUIhBXi4FAmPVYy0PHHVsbUBnZW50 b28ub3JnAAoJEFGIM1CIQV4u+EEH/jXrvsc52qBX29x2lBDq36u4ug8PcvOeGxTz z9Pp4r7c5g53+3ND6BLL6wUwv2/AEFFVxfQX9ppJFYvIxW6RfJheoIl856qXfEdC kJPGYuKDByeI+tYMex8MPpxipHHQHIRbhvpcMHOD9cekMsNCV/IQ4msgx+dF0UX8 opc2ZcAvYO4waYOM6JXe5YNJlBxETQlMtczJ9eQS5rH2rn3Fc8/E560me0UFjwN0 +ZojkN67IIP0TtGhvv0BflrdMYqY4R/q6qnFKF3lwOyNGQnqzrE9GAn3aKFkZWD5 Rj77a7Ivg2un3BAGtm8XLJna5ank+4150/PRJU1+C8lIbHlrZ24=ViyU
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I'd prefer if PyPI names are guidelines, not a strict policy. I don't
like CamelCase and separators other than dash ("-") :P

Also I don't like when packages are named "dev-python/python-foo"
instead of just "dev-python/foo".

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 28/01/2023 19:02, Ulrich Mueller wrote:

On Sat, 28 Jan 2023, Michał Górny wrote:

However, it's been pointed out that this makes it hard for people to
find packages they're looking for.

I don't understand this argument. Why would all-lowercase make finding a package harder?

Here's an example, on pypi we have packages:
- git-python
- python-git
- GitPython
- git-py

Each of these is a different package. The package you usually want is GitPython, but if we would name it gitpython or git-python, things would
get very confusing very quickly. In fact, this package was renamed
precisely to avoid this confusion in [1]. This is not the only case
where there are very similarly named packages on pypi. By having a 1 to
1 mapping between names in pypi and names in ::gentoo we avoid this
confusion.

Best regards,
Andrew

[1] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0dec450a90c7490f11df7e69cd9c6709c099285c

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-01-28 19:02, Ulrich Mueller wrote:

On Sat, 28 Jan 2023, Michał Górny wrote:

However, it's been pointed out that this makes it hard for people to
find packages they're looking for.

I don't understand this argument. Why would all-lowercase make finding a package harder?

It doesn't.
`eix` search is case-insensitive.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 2023-01-28 at 22:15 +0500, Anna (cybertailor) Vyalkova wrote:

I'd prefer if PyPI names are guidelines, not a strict policy. I don't
like CamelCase and separators other than dash ("-") :P

Also I don't like when packages are named "dev-python/python-foo"
instead of just "dev-python/foo".

So instead you claim "foo" and block adding actual "foo" later?

--
Best regards,
Michał Górny

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 28/01/2023 17.38, Michał Górny wrote:

To improve consistency and make packages easier to find, I'd like to
propose going forward that when packages are published on PyPI, we use
their official PyPI names. This also means preserving the case for
the few packages that use CamelCase names and similar.

Consistency is generally a good thing. So +1

FTR, I think this should probably be applied in general in such
situations, and not just for the Python ecosystem.

- Flow

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 28 Jan 2023, Andrew Ammerlaan wrote:

Each of these is a different package. The package you usually want is GitPython, but if we would name it gitpython or git-python, things
would get very confusing very quickly. In fact, this package was
renamed precisely to avoid this confusion in [1]. This is not the only
case where there are very similarly named packages on pypi. By having
a 1 to 1 mapping between names in pypi and names in ::gentoo we avoid
this confusion.

Looking at mgorny's list, you cannot have an 1 to 1 mapping anyway,
because that would result in invalid PN names.

-----BEGIN PGP SIGNATURE-----

iQFDBAEBCAAtFiEEtDnZ1O9xIP68rzDbUYgzUIhBXi4FAmPVkmEPHHVsbUBnZW50 b28ub3JnAAoJEFGIM1CIQV4uLGgH/3vnx4JOeqmSR69AAM1zGTaKrwfDpiAJxBRi wCXkCJoA66NOr9sU9LdE5R6KIDLYdC8yZtpG/1EnITGRF82DT6ENldzknlV478Go yC+ndeIXQ431u8hvnI+Cj5lvPVGDyGSxdzqq+Yg+LUkEaFNplBepswUjtfd22d4N xnty5StzR0iHlbXm/khjRr2Ya3/UzvSA3Q1UYajwoMkrzlwX3Rf8mZ9zhX1g5Ym/ ZqSKLLgpE5NJ/lc8gpTYGdT0Ppr8LfCw03ctSHeL4BP11SXKtxe65HFq+sGPepvN JRJU0i35vb3AeXVy/eI941Qyg/yA57q0flcwyNiJsKxS5CQypMg=
=zSWg
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2023-01-29 at 02:15 +0300, Torokhov Sergey wrote:

As for replacing dot  (".") with hyphen ("-") I have PyPi package
"FoBiS.py" that is packaged in ::guru just as "FoBiS" as I wasn't sure
is it worth to store ".py" suffix while github repo of this project is
just "FoBiS". So there could be a problem if package named "fobis"
will appear in PyPi.

Thanks for this example. This is actually a perfect case that makes you really, really think about dropping ".py" and a perfect explanation why
we should keep it, even if it makes the package name look "unnatural".

--
Best regards,
Michał Górny

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Jan 29, 2023 at 02:15:19AM +0300, Torokhov Sergey wrote:

<div>The similar names in PyPi is a real problem for users when trying to find associated packages. It's also could be a security issue for them with malicious packages named like popular packages. </div><div><br /></div><div>So in ::guru I try to

save package naming even if it's too  CamelCase.</div><div><br /></div><div>As for replacing dot  (".") with hyphen ("-") I have PyPi package "FoBiS.py" that is packaged in ::guru just as "FoBiS" as I wasn't sure is it worth to store ".py" suffix while
github repo of this project is just "FoBiS". So there could be a problem if package named "fobis" will appear in PyPi.</div><div><br /></div><div>28.01.2023, 19:38, "Michał Górny" &lt;mgorny@gentoo.org&gt;:</div><blockquote><p>Hi, everyone.<br /><br />
TL;DR: I'd like to propose naming dev-python/* packages following PyPI<br />names whenever possible, case-preserving, with modifications only when<br />necessary to match PN rules.<br /><br /><br />So far the naming in dev-python/* hasn't been exactly
consistent. <br />Myself I've been mostly following "whatever's the easiest" policy which<br />generally meant following GitHub project names whenever we fetched from<br />there.<br /><br />This mostly made sense so far, as I've been thinking of dev-
python/<br />primarily in terms of dependencies of other packages. However, it's<br />been pointed out that this makes it hard for people to find packages<br />they're looking for.<br /><br />The vast majority of packages in dev-python/ are also
published on PyPI<br />[1]. They can afterwards be installed using tools such as pip, or<br />specified as dependencies of other projects — using their PyPI names<br />in every case.<br /><br />On top of that, it is not unknown for multiple packages
with very<br />similar names to coexis, say "foo", "pyfoo" and "python-foo". When GH<br />project names come into the picture, this can get even more ambiguous. <br />Don't even get me started about developers pushing duplicate packages<br />because
they didn't find the existing instance.<br /><br /><br />To improve consistency and make packages easier to find, I'd like to<br />propose going forward that when packages are published on PyPI, we use<br />their official PyPI names. This also means
preserving the case for<br />the few packages that use CamelCase names and similar.<br /><br />Some modifications will be necessary. For example, it is legal for PyPI<br />package names to include dot (".") — we normally translate that to a<br />
hyphen ("-"). We may also have use cases for creating multiple Gentoo<br />packages from the same PyPI package (see e.g. dev-python/ensurepip-*). <br />Then, there are of course Python packages that aren't published on PyPI.<br /><br />Still, I think as
a general rule of thumb this would make sense. WDYT?<br /><br /><br />[1] <a href="https://pypi.org/" target="_blank">https://pypi.org/</a><br /><br /></p><span class="f55bbb4eeef208e8wmi-sign">-- <br />Best regards,<br />Michał Górny<br /></span></
blockquote>

Can you send plaintext mail to gentoo-dev? HTML makes it very hard to read your mails in certain clients.

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQQyG9yfCrmO0LPSdG2gXq2+aa/JtQUCY9bWzgAKCRCgXq2+aa/J teSXAP9Y9aisB/1cj0O79XUyTa1ZCzfVKCAcYRnJ7DM3M/DM5gD+ITzWpN+662ns Itr/CMAh8uE6/uhvHVaqUz3GEl13ig4=
=IHmT
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Jan 28, 2023 at 10:23:45PM +0100, Ulrich Mueller wrote:

On Sat, 28 Jan 2023, Andrew Ammerlaan wrote:

Each of these is a different package. The package you usually want is GitPython, but if we would name it gitpython or git-python, things
would get very confusing very quickly. In fact, this package was
renamed precisely to avoid this confusion in [1]. This is not the only
case where there are very similarly named packages on pypi. By having
a 1 to 1 mapping between names in pypi and names in ::gentoo we avoid
this confusion.

Looking at mgorny's list, you cannot have an 1 to 1 mapping anyway,
because that would result in invalid PN names.

Should imperfection get in the way of bettering the mapping?

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQQyG9yfCrmO0LPSdG2gXq2+aa/JtQUCY9bWcgAKCRCgXq2+aa/J tbqLAP9IZxCMkXT07sfrKDZg2RZNlMglHcSGnV4Ypu3uB8lcvgEA7wXTN/QI3bJh 1RSdxPXVhpsWlNaSUdXcPjdXm1PO9Qo=
=eMDp
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Jan 28, 2023 at 10:15:02PM +0500, Anna (cybertailor) Vyalkova wrote:

I'd prefer if PyPI names are guidelines, not a strict policy. I don't
like CamelCase and separators other than dash ("-") :P

Also I don't like when packages are named "dev-python/python-foo"
instead of just "dev-python/foo".

So, two simply aesthetic opinions. I'm not sure it's appropriate to
suggest one's aesthetic preference as default when there's no further
benefit.

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQQyG9yfCrmO0LPSdG2gXq2+aa/JtQUCY9bWFAAKCRCgXq2+aa/J tWloAPwNUHucqMvIvPc1UeUrry76IBD3hPvFV42BH1iGiybkKwD/QPUssECybNPH 3byPzBCKm0aefBkYQ/5g+teVjaRfvwI=
=egEg
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 2023-01-28 at 17:38 +0100, Michał Górny wrote:

To improve consistency and make packages easier to find, I'd like to
propose going forward that when packages are published on PyPI, we use
their official PyPI names. This also means preserving the case for
the few packages that use CamelCase names and similar.

Some modifications will be necessary. For example, it is legal for PyPI package names to include dot (".") — we normally translate that to a
hyphen ("-"). We may also have use cases for creating multiple Gentoo packages from the same PyPI package (see e.g. dev-python/ensurepip-*).
Then, there are of course Python packages that aren't published on PyPI.

Still, I think as a general rule of thumb this would make sense. WDYT?

To add a data point, the "Flask-Babel" package has been renamed to "flask-babel" upstream today. Unfortunately, minor changes to names are
not that uncommon (pkgcheck regularly catches them via "mismatched" remote-ids). This also means that now this one package is inconsistent
with the rest of capitalized "Flask" packages.

In the end, I'm still not sure whether this policy really makes sense.
Perhaps it should be relaxed to allow case mismatches, if only to allow
us to retain in-tree consistency when upstreams fail to be consistent.

However, there's a can of worms around the corner -- should we also
allow normalizing "-" and "_" across different packages (see dev- python/sphinx*)?

Now you see why we didn't have a policy for this before.

--
Best regards,
Michał Górny

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Andrew Ammerlaan <andrewammerlaan@gentoo.org> writes:

On 28/01/2023 19:02, Ulrich Mueller wrote:

On Sat, 28 Jan 2023, Michał Górny wrote:

However, it's been pointed out that this makes it hard for people to
find packages they're looking for.

I don't understand this argument. Why would all-lowercase make finding a
package harder?

Here's an example, on pypi we have packages:
- git-python
- python-git
- GitPython
- git-py

Each of these is a different package. The package you usually want is GitPython, but if we would name it gitpython or git-python, things would get very confusing very quickly. In fact, this package was renamed precisely to avoid this confusion in [1]. This is not the only case where there are very similarly named packages on pypi. By having a 1 to 1 mapping between names in pypi and names in ::gentoo we avoid this confusion.

AFAIK, but I cannot find a source confirming this, PyPI project names
are case-insensitive, so it should be okay to map to all lowercase.

Best regards,
Andrew

[1] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0dec450a90c7490f11df7e69cd9c6709c099285c

--
Arsen Arsenović

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iOcEARYKAI8WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCY9eqKV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxEcYXJzZW5AZ2Vu dG9vLm9yZwAKCRBSwpQwHqLEk1oBAQDkqT+rcu3EhE3lvaOTY8sZWYPKhGvgj6wa I9aqz2gQkAD/SdrKmsdjEfFpVrNacCMTaHREpaeqsTNc8Kt2UNPuDAg=rUpE
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 2023-01-30 at 16:11 +0500, Anna (cybertailor) Vyalkova wrote:

On 2023-01-30 12:00, Michał Górny wrote:

However, there's a can of worms around the corner -- should we also
allow normalizing "-" and "_" across different packages (see dev- python/sphinx*)?

PyPI treats "-" and "_" separators as the same, so I'd not use
underscores for in-repo consistency.

I suppose that's PEP 503. It speaks of name normalization:

| The name should be lowercased with all runs of the characters ., -,
| or _ replaced with a single - character. [1]

Technically, a policy that would require only "normalized" name match
would let us improve consistency when upstreams fail to do so.
Unfortunately, while common tools search case-insensitively, they are
sensitive to these characters (and I'm not convinced of changing that).

[1] https://peps.python.org/pep-0503/#normalized-names

--
Best regards,
Michał Górny

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-01-30 12:00, Michał Górny wrote:

However, there's a can of worms around the corner -- should we also
allow normalizing "-" and "_" across different packages (see dev- python/sphinx*)?

PyPI treats "-" and "_" separators as the same, so I'd not use
underscores for in-repo consistency.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 2023-01-28 at 17:38 +0100, Michał Górny wrote:

Hi, everyone.

TL;DR: I'd like to propose naming dev-python/* packages following PyPI
names whenever possible, case-preserving, with modifications only when necessary to match PN rules.

The "relaxed" version is now official:

https://projects.gentoo.org/python/guide/package-maintenance.html#package-name-policy

--
Best regards,
Michał Górny

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)