You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is not uncommon for importable packages to have different names than the repositories (or distributions) that hold them, so {{cookiecutter.repo_name}}/{{cookiecutter.repo_name}} should use two distinct variables.
project_name is not a drop-in for either, since it can include spaces and capital letters.
It seems like maybe there should be an additional option declared between repo_name and first_module_name.
Also, it seems a bit odd to default to creating the first module as projectname/projectname.py. Would it be reasonable to change the default to the proposal from the workshop material? (i.e. functions?)
It is not uncommon for importable packages to have different names than the repositories (or distributions) that hold them, so
{{cookiecutter.repo_name}}/{{cookiecutter.repo_name}}
should use two distinct variables.project_name
is not a drop-in for either, since it can include spaces and capital letters.It seems like maybe there should be an additional option declared between repo_name and first_module_name.
Also, it seems a bit odd to default to creating the first module as
projectname/projectname.py
. Would it be reasonable to change the default to the proposal from the workshop material? (i.e.functions
?)Then, the template directory structure can be updated to
{{cookiecutter.repo_name}}/{{cookiecutter.package_name}}
The text was updated successfully, but these errors were encountered: