search

pypa / hatch

Modern, extensible Python project management
https://hatch.pypa.io/latest/
MIT License
6.05k stars 306 forks source link

Consider to improve `hatch new` with more options #660

Open tomschr opened 1 year ago

tomschr commented 1 year ago

Thanks for this great project! :heart:

Situation

The command hatch new has an interactive mode. For me as a new user this is great as it allows that I can enter all the necessary data to create a correct TOML file. Hatch uses already some useful defaults and this is great.

However, comparing it to poetry init, it's rather limited in regards to what you can define. For example, you cannot define the author, a description, or other metadata about the project.

Proposal

I would propose to extend the hatch new with some more options.

For example, poetry init --help has these options:

Output of poetry init --help ``` $ python3 -m poetry init --help Description: Creates a basic pyproject.toml file in the current directory. Usage: init [options] Options: --name=NAME Name of the package. --description=DESCRIPTION Description of the package. --author=AUTHOR Author name of the package. --python=PYTHON Compatible Python versions. --dependency=DEPENDENCY Package to require, with an optional version constraint, e.g. requests:^2.10.0 or requests=2.11.1. (multiple values allowed) --dev-dependency=DEV-DEPENDENCY Package to require for development, with an optional version constraint, e.g. requests:^2.10.0 or requests=2.11.1. (multiple values allowed) -l, --license=LICENSE License of the package. -h, --help Display help for the given command. When no command is given display help for the list command. -q, --quiet Do not output any message. -V, --version Display this application version. --ansi Force ANSI output. --no-ansi Disable ANSI output. -n, --no-interaction Do not ask any interactive question. --no-plugins Disables plugins. --no-cache Disables Poetry source caches. -C, --directory=DIRECTORY The working directory for the Poetry command (defaults to the current working directory). -v|vv|vvv, --verbose Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug. Help: The init command creates a basic pyproject.toml file in the current directory. ```

I don't think we need to implement all, but it would be nice to have some more. For example, I think the following optional options are probably the most useful:

The above options should be asked in the interactive mode as well, possibly shown with some default values if possible.

Surely, there could be done more, but that would be out of scope for this issue. For example:

Benefits

funkyfuture commented 1 year ago

URLs can be defined much more versatile than having a project URL.

i don't see the benefit in user-friendliness, if a developer is using a pyproject.toml s/he should learn what is necessary for them to handle it properly.

personally i prefer editing text files, b/c usually i want to change what i had quickly fed to a prompt to get forward anyway.

what leads to my wish: please don't replicate poetry! having that said, i don't see feature parity as a benefit neither.

mind that there is cookiecutter and alike tools if you want to initialize a well-defaulted project convolute.

tomschr commented 1 year ago

Thanks for your feedback.

I don't see the benefit in user-friendliness, if a developer is using a pyproject.toml s/he should learn what is necessary for them to handle it properly.

I disagree. :slightly_smiling_face: Is it user-friendly if you are in the middle of creating a new project and need to search for all the necessary options just to create the right TOML structure?

Of course it's documented, but I think it's a context switch. Sure, you can't configure everything, but at least you can have a minimal working example which you can fine-tune later. I would count that as very user-friendly!

Regarding learning: yes, we all need to learn something new all day. However, there are limits. And sometimes we are lazy, in a hurry and want a quick solution, or it's just overwhelming. Here a new config file for this tool, there a new format, etc. Soon, you are "learning" not only this pyproject.toml file, but more. Especially if you are a beginner it can be too much to get all the details right.

If experts like you prefer to edit the file directly, this is still possible. Nobody will force you to change it. Nor it is generally disallowed. But please consider there are other groups which would benefit from this.

It's all about to make it possible for not so experienced developers. But even experts have sometimes use cases to create this TOML file quickly.

The question is, what's the target group for this project?

please don't replicate poetry!

That's not the intention of this issue. However, if you look around you will notice all these new tools have a new subcommand. It would be at least consistent to the other tools. If someone switches to hatch, they find it easier to use it as they already know this subcommand.

mind that there is cookiecutter and alike tools [...]

Yes, there are lots of tools that can be used. But that's not the point. People should be able to use it without relying on 3rd party tools.

funkyfuture commented 1 year ago

thank you for your response as well.

i'm sparing replies to yours where our different perspectives necessarily lead to contradictions.

The question is, what's the target group for this project?

that's the point, i thought it's for people who need a tool that does its job without any extra glitter attached. but the reality is likely more diverse.

given that the ecosystem evolves on its own pace and people might need choices, that imo is a point to develop the related plugins in a seperate git repository. yet, with the current architecture it will be difficult to combine different ones.

personally i'd be fine with a minimal template, but given the recent, unreleased additions i abstain from using the new command. it doesn't make a difference whether i assemble the convolute myself or carefully strip the templates off the choices i didn't make.

this also concerns the two or three issues where the initial contents of a .gitignore are discussed.