Consider different wording for "Is the project a library that is installable?"

[noamraph]

Is your feature request related to a problem? Please describe.

I want to make an installable tool. I first answered "no" to "Is the project a library that is installable?", but actually I do want to give the project description, build backend, etc.

Describe the solution you'd like

Perhaps change the wording to "Is the project a library or a tool that is installable?"

Perhaps there should be a different treatment for a library and an executable tool.

Actually, I would expect an executable tool to start with a "hello world" template.

[frostming]

Maybe

Is the project installable as a Python package?

[noamraph]

It is better, but feels still confusing to me.

The truth is, I don't know exactly the intended meaning of the question.

Cargo has two modes: executable (cargo init hello), and library (cargo init --lib hello). Perhaps this should be the first question?

I don't know what's exactly the intent of a "non-installable" project. It seems to me that the main reason for using something like pdm is to allow others or myself to install what I did on another environment and have it work. Why not always define a package?

[frostming]

A typical web app is not installable right? People don't want to specify the extra info that is only required for an installable package.

[noamraph]

What exactly is the extra info? I wouldn't mind an extra "description" question that I can leave blank. And regarding version, I think that it's reasonable to just always start with "0.1.0", as Cargo does. Are there any additional questions?

[frostming]

No all people like to install the project every time: #2492 (comment)

[noamraph]

I don't think I really understand the use case of --no-self - what's the advantage of not having the project package installed? Is it a way to just specify a venv with some dependencies, without .py files in the directories installed?

If so, I think those are 3 distinct uses:

1. A library
2. An executable
3. A venv

WDYT?

[sanmai-NL]

@noamraph --no-self allows one to install the dependencies. When the developer changes their own product's source code, they can install it without having to iterate all the dependencies. This can then be leveraged for optimized builds, e.g. for container images.

[noamraph]

@sanmai-NL from what I see, the "self" package is installed in the venv in editable mode, so when the developer changes their own product's source code, it is automatically available in the venv. So I'm sorry, I still don't understand: when would you use --no-self (or package-type = "application", which seems to do the same thing)?

[sanmai-NL]

I'm not claiming there are no alternative workflows, just noting a possible need from another user's perspective.

I don't install editable packages in container images, as they're not supposed to be editable there.

[frostming]

• A library
• An executable
• A venv

Didn't you make a folder with many scripts or a Django app that can't be installed from PyPI?