astral-sh / rye

a Hassle-Free Python Experience
https://rye.astral.sh
MIT License
12.8k stars 443 forks source link

[feature] Project templates #87

Open con-f-use opened 1 year ago

con-f-use commented 1 year ago

In larger organizations, it is often useful to have some kind of tmeplate for starting new python projects to encourage (organizational) best practices. A popular solution for python projects would be the Cookiecutter project.

I was even thinking of some kind of mechanism, where something like django or other larger packages could define a template and rye would be able to list that (and others) as a possible project starter if django (or whatever) is already installed. Sort of an entrypoint-system or plugin system for project templates, that rye would provide and other packages could hook into, registering their templates with rye. Just an idea. You could also just wrap Cookiecutter, which takes git repository URLs for external templates, or leave it out completely. Packaging just has a lot of biolerplate, that a unified tool could take care of.

As for the interface, Hatchet has

hatchet new --ci --tests --docs

if I remember correctly. Rye could have a similar

rye init --app/--library --ci --tests --docs --django --vcs-versions --jupyter ...

Not saying I want rye to have these, just giving options (literally :grin: ).

cnpryer commented 1 year ago

I'd love for rye to have opinions. If rye has opinions here less is probably better. This does sound like plugin territory. I see this like rye supporting any other default. If there is a default it probably should be pretty minimal. I'm a fan of the src layout.

Here's an example project of mine:

xlcsv on ξ‚  master is πŸ“¦ v0.1.0 via 🐍 v3.11.0 
❯ tree .
.
β”œβ”€β”€ LICENSE
β”œβ”€β”€ Makefile
β”œβ”€β”€ README.md
β”œβ”€β”€ pyproject.toml
β”œβ”€β”€ requirements-dev.lock
β”œβ”€β”€ requirements.lock
β”œβ”€β”€ src
β”‚Β Β  └── xlcsv
β”‚Β Β      β”œβ”€β”€ __init__.py
β”‚Β Β      β”œβ”€β”€ error.py
β”‚Β Β      β”œβ”€β”€ io.py
β”‚Β Β      └── utils.py
└── tests
    β”œβ”€β”€ __init__.py
    β”œβ”€β”€ test_convert.py
    └── test_version.py
mitsuhiko commented 1 year ago

I think rye should not support templates in the core of it, but I'm a strong believer in promoting good defaults. I feel like rye init shoudl at least also create an src/project_name/__init__.py file.

con-f-use commented 1 year ago

Yeah, this more a brainstorm than a feature request. Whole-hearted :+1: for src layout.

If rye init created src/project_name/__init__.py that is already dangerously close to a template. Maybe providing a rye init --template <name_or_url> or --from <template> something and then delegating that to a configurable external command, is an option?

mitsuhiko commented 1 year ago

What I really like about the cargo experience is that on an empty folder it puts you on the path of success. It creates src/lib.rs which is exactly what you want in 99% of cases. I think the same should apply to rye. You should be using src/package-name, so why not create it?

con-f-use commented 1 year ago

Yeah no, I absolutely meant that that should be the default behavior for rye init without further arguments. The --template would be a very optional, user/organization/project configurable type of thing in my mind.

martin-liu commented 1 year ago

I think tests (and coverage) config should be by default added when do rye init, probably also linting.

cargo new don't add tests config only because it has built-in support.

trymzet commented 4 weeks ago

I initially also thought it would be nice, but then I realized running cookiecutter gh:my-gh-org/my-cookiecutter-template-repo is literally the same amount of effort as running rye init --template gh:my-gh-org/my-cookiecutter-template-repo, so why bother πŸ˜