Support running scripts with default arguments

[domoritz]

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the documentation and believe that my question is not covered.

Feature Request

I would like to run a script like poetry run test, which should run pytest package.

However, I could not find a way to add an argument to the script.

[tool.poetry.scripts]
test = "pytest:main"

It would be great if scripts had default arguments.

[thejcannon]

+1 for the default args. (Although I think poetry test should be another command)

[domoritz]

Although I think poetry test should be another command

What do you mean?

[thejcannon]

poetry takes inspiration from cargo, which has a test command.

So I believe poetry test should be an additional command, but don't feel strongly enough or have enough of an idea of an implementation to make an issue.

[domoritz]

Yarn automatically runs commands when the command is not another builtin (yarn XXX means yarn run XXX unless XXX is a command yarn already has reserved (such as run itself).

[abn]

As things stand, this is not something that poetry will support out of the box. If such a feature is required, it might be better suited for a plugin once the plugin system is available. A plugin that allows for alias commands to be specified.

That said, once #2310 completes, you should be able to use custom scripts by adding file. We are aware that this is not the same as having aliases defined.

This can be re-evaluated later after plugin support is added. Closing for now.

[funkyfuture]

@domoritz, @thejcannon, why wouldn't a poetry run pytest <tests_folder> be working for you?

[thejcannon]

It would, but it's more of a convention-thing to have a built-in command that runs the tests.
That being said, I think over time I've realized I doubt it's worth it, so... 🤷‍♂️

[funkyfuture]

well, setuptools offers a similar approach to define a test command and even dependencies for ages. but my observation is, that it's hardly used, maybe even declining. i think this is caused by the usage of more versatile tools like tox (or nox) and CI platforms. e.g., these are used to run different kind of tests (unit, linting, type checks). personally, i keep these in a Makefile, e.g.:

black:
    black src

linting:
    poetry run flake8 src

unit:
    poetry run pytest src

tests: black linting unit

(note,that the tests target shouldn't be run in a CI environment in this case, b/c it may alter the source. this is a convenience target for development.)

[domoritz]

I do a lot of JavaScript development and like that most of my development scripts are in a the package.json file. Yes, I could use a makefile in python but out of convenience I’d prefer to define shortcuts in poetry directly.

[funkyfuture]

i think the developer's consensus is that you can put your shortcuts into a pyproject.toml, but you need a task runner tool for that. that's out of poertry's scope.

[domoritz]

@funkyfuture I'm not following. How does one define shortcuts in a pyproject.toml and what's a task runner tool (Make?).

[funkyfuture]

i mean that there can other tools that read their configuration from the pyproject.toml, but not poetry's namespace. one such other tool can be a task runner.

I would like to run a script like poetry run test, which should run pytest package.

that's what a task runner can facilitate.

i checked a few months back, but there were no task runners that make use of pyproject.toml at that time.

[domoritz]

Thanks for the explanation.

[ypicard]

Coming from the Javascript ecosystem, I find it hard to believe a discussion is even needed for this kind of topic. How can native arguments not be natively supported, and what are the arguments against implementing it? There are so many forum threads trying to figure out how to enable this, I think this just shows the community would like to see this supported by default.

Adding other scripts using other tools just feels like a hack.

I would really like to understand the difference in philosophy between the 2 communities here.

[castarco]

Disclaimer: this is a short rant (skip it if you're looking for a useful comment), about Python, not Poetry. Sorry, but I had to say it.

@ypicard you're right. Python is overcomplicated when it comes to packaging and configuration, with few benefits in exchange for that extra complexity. It has been like that for around 20 years, and the solutions that are usually proposed don't improve much over the previous state of things.

The biggest problem is that most prolific Python developers already have a ton of hacks in place, and they don't feel the pain because of those hacks and memorized tricks (it reminds me to the Assembler programmers that refused using C, because they already learnt a lot of smart tricks to overcome the major pain points); then a lot of newbies arrive to the community, without prior experience on other development environments... and they end up believing that this state of things is normal, or "okish". And it's not, it's a total clusterfuck.

Poetry makes it a bit nicer, but not much; as it's not its responsibility, to be honest.

Every time I've said that in public I received a shower of negative comments, and probably other people had the same experience. So I lost any faith on the project, since criticism is not well taken. I abandoned Python years ago because of that, and I only use it when I'm forced to.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.