Improving default for project_slug

[matt-graham]

I think the default for project_slug could possibly be improved - specifically I'm not sure replacing spaces and underscores in project_name with hyphens gives a good model of what this should be as to be a valid package or module name we cannot have hyphens and to align with PEP8 recommendations we shouldn't have underscores in the package name either.

Originally posted by @matt-graham in #108 (comment)

Somewhat relatedly I wonder if we should also add a pre-generate hook to check whether the project_slug chosen conflicts with an existing package (distribution) on PyPI (probably just warning the user rather than preventing this being possible).

[paddyroddy]

Just so you know where that came from https://github.com/audreyfeldroy/cookiecutter-pypackage/blob/7696a30f4fb66c6c87815c51e12e7c7e3985e844/cookiecutter.json#L6

[samcunliffe]

I seem to remember we discussed this in hackday 3...? Or am I misremembering?

I think the choice to have "Project name" → project-name as the package name and project_name as the actual importable python module was deliberate. Certainly, the underscores and hyphens thing is the convention (I'm not sure if it's only defacto the convention...)

Napari and pytest extensions do this, e.g.

• napari-matplotlib is napari_matplotlib but napari-matplotlib on pypi
• pytest-mpl is pytest_mpl ditto on pypi

Or do I misunderstand your comment, Matt?

+1 to this...

I wonder if we should also add a pre-generate hook to check whether the project_slug chosen conflicts with an existing package (distribution) on PyPI

If the name is taken then our user should think of a different name. (Since we specifically want to encourage the distribution of research code.)

[paddyroddy]

I agree with @samcunliffe here - you see those examples everywhere. Whilst _ aren't ideal in the package names, enough have been taken that people will be doing it more and more often.

[samcunliffe]

https://pypi.org/project/pkg-name-validator/

Looks like it does what we want. Even better if we could find a premade pre-generate hook to do this. Feels like someone must have...

[matt-graham]

I think the choice to have "Project name" → project-name as the package name and project_name as the actual importable python module was deliberate. Certainly, the underscores and hyphens thing is the convention (I'm not sure if it's only defacto the convention...)

This might be where I'm misunderstanding things, but I thought the current set up is such that the project_slug is used directly for setting both the name of the package directory as src/{{cookiecutter.project_slug}} and name of the module created inside that directory as src/{{cookiecutter.project_slug}}/{{cookiecutter.project_slug}}.py? So if I use "Test project" for the value for project_name when prompted, I end up with project_slug equal to test-project and a module src/test-project/test-project.py which is not importable?

[matt-graham]

Just so you know where that came from https://github.com/audreyfeldroy/cookiecutter-pypackage/blob/7696a30f4fb66c6c87815c51e12e7c7e3985e844/cookiecutter.json#L6

But the replacements there are different from what we have right? Theirs:

  "project_slug": "{{ cookiecutter.project_name.lower().replace(' ', '_').replace('-', '_') }}",

versus our

  "project_slug": "{{ cookiecutter.project_name.lower().replace(' ', '-').replace('_', '-') }}",

So we replace space and underscores with hyphens while they replace spaces and hyphens with underscores (which would give a valid package / module name).

[matt-graham]

I think the choice to have "Project name" → project-name as the package name and project_name as the actual importable python module was deliberate. Certainly, the underscores and hyphens thing is the convention (I'm not sure if it's only defacto the convention...)

I think some of the confusion here might be in what we are referring to as a package. I would refer to the package as the importable directory containing an __init__.py file and the archive we upload to PyPI as a distribution:

https://the-hitchhikers-guide-to-packaging.readthedocs.io/en/latest/glossary.html#term-package
https://the-hitchhikers-guide-to-packaging.readthedocs.io/en/latest/glossary.html#term-distribution

I've been assuming what determines the name on PyPI is the distribution not package but I'm not sure on this point and it seems there is an inherent level of inconsistency in all of this

[paddyroddy]

It is very possible there are mistakes. Not sure if the cookiecutter tests this thing - they should.

[samcunliffe]

Bug!

(base) ➤ cookieninja gh:ucl-arc/python-tooling
author_name [UCL ARC]: Sam Cunliffe
author_email [[email protected]]: [email protected]
github_username [Sam-Cunliffe]: samcunliffe
project_name [Python Template]: My Excellent Python Package With Spaces In The Name
project_slug [my-excellent-python-package-with-spaces-in-the-name]:
project_short_description [A cookieninja template with ARC recommendations.]: A really excellent python package.
funder [JBFC: The Joe Bloggs Funding Council]:
Select licence:
1 - MIT
2 - BSD-3
3 - GPL-3.0
Choose from 1, 2, 3 [1]: 1
Select min_python_version:
1 - 3.9
2 - 3.10
3 - 3.11
Choose from 1, 2, 3 [1]: 3
Select max_python_version:
1 - 3.11
2 - 3.10
3 - 3.9
Choose from 1, 2, 3 [1]:
(base) ➤ tree my-excellent-python-package-with-spaces-in-the-name
my-excellent-python-package-with-spaces-in-the-name
├── LICENCE.md
├── README.md
├── pyproject.toml
├── src
│   └── my-excellent-python-package-with-spaces-in-the-name
│       └── my-excellent-python-package-with-spaces-in-the-name.py
└── tests
    └── test_dummy.py

4 directories, 5 files
(base) ➤

[samcunliffe]

Ah and we don't test for it, because we give the project slug directly without spaces in the test.

→ now a failing test in 9151ae5