ASFHyP3 / hyp3-cookiecutter

Cookiecutter to quickly generate a new HyP3 Plugin
BSD 3-Clause "New" or "Revised" License
4 stars 4 forks source link

Project names that do not include `hyp3` cause pyproject.toml failure #9

Closed forrestfwilliams closed 1 year ago

forrestfwilliams commented 1 year ago

Currently the cookiecutter assumes that the project's name begins with Hyp3- otherwise it will break in subtle ways when provided the default names. Do we want to enforce this assumption, or allow people to create a wider variety of project names?

jtherrmann commented 1 year ago

We were getting an error when attempting to pip install the resulting package when package_name and process_name are the same, because this results in two entrypoints in pyproject.toml with the same name. This happened when we would choose a package name that did not include hyp3, because then there would be no occurrence of hyp3 to be replaced by proc (see https://github.com/ASFHyP3/hyp3-cookiecutter/blob/update_staging/cookiecutter.json#L7) so then package name and process name would end up the same.

We fixed this with https://github.com/ASFHyP3/hyp3-cookiecutter/pull/8/commits/3ec72b02b3bf8bd397745b1ab717189733e08997 by forbidding the user from setting package name and process name the same. This may be sufficient to close this issue, but we may still want to think more about whether we are giving the user too many choices for customization (see https://github.com/ASFHyP3/hyp3-cookiecutter/blob/update_staging/cookiecutter.json) and whether we should perhaps handle more of that stuff behind the scenes.

jtherrmann commented 1 year ago

Right now, this is most likely to occur to someone when they leave out hyp3 from their project_name, and the error message (ERROR: package_name and process_name must be different!) is probably not very helpful.

jhkennedy commented 1 year ago

Oh, this is a good question!

I think we can drop the console script entry points entirely, eliminating the pyproject.toml issue -- see: #10

But it's worth thinking about the name and prompts overall.

Typically, we've followed the pattern:

This is a good pattern overall, I think, for plugins and would want to "strongly suggest" but not necessarily enforce (e.g., RAiDER was an existing package we added HyP3 functionality to). Though for a plugin cookie-cutter, do we want to enforce a hyp3 prefix?

The next part, I've always disliked what I settled on, and I don't know if there's a good convention for it.

There's

I want users to be able to name this function appropriately (descriptively), so we should likely prompt for that name, so we added:

The process_type is only used to populate the __main__ docstring and the process.py module docstring

jhkennedy commented 1 year ago

:thinking: The minimal description of a hyp3-plugin is:

A HyP3 plugin runs a process (workflow) that creates a product and uploads it to AWS S3.

maybe we should do something like:

and it might even make sense to rename process.py workflow.py.

If we ensured product_name conformed to a python package regex, we could even not prompt for any of the sub-bullets.

Edit: We actually might want to update the PACKAGE_REGEX to ^[_a-z][_a-z0-9]+$: https://peps.python.org/pep-0008/#package-and-module-names