Suppose I plan to publish a Python library package to PyPI, and I’m interested in creating a CLI interface for it. The code that translates CLI input to library function calls doesn’t add significant logic.
Which is considered the best practice:
Adding the CLI code to the library package, which installs the CLI script when the library package is installed.
Creating another package that only contains the CLI script that depends on the library package. The dependency version is pinned so that the the CLI package and library package have a one-to-one mapping.
The answer is the ever helpful “you can do it either way!”
I would suggest creating a separate CLI package, having worked on CLI frontends for several tools. Your CLI may evolve to want packages like click which you wouldn’t want your core library to require.
Keeping the two separate will cost you a little more work right now to set up the packages, but will put you in a more flexible position moving forward.
All of that is said based on the assumption that you plan to consider the projects stable relatively soon. If you want to go through some rapid iterations first, in a series of pre-“1.0” releases, keeping the two together may make your work more efficient.
Also, I think this should move to the Help forum, as it’s really a packaging help topic.
That may be true now, but are you certain it will remain so?
Having faced this exact question in one of my own packages, and opted for the former solution (CLI as part of the library package), in retrospect I would have chosen the latter (CLI in a separate package). In my case, the CLI code has grown significantly, to the point that it is nearly as large as the library itself (due to CLI-specific things like output formatting and input error handling).
In any future packages where I am faced with this question, I will always go for option 2.