I think you may be confusing two things. Having a src directory in your source distribution is a reasonably common, idiomatic thing to do; having that in the installed package or app, not so much.
There are two basic ways to structure this.
First, you can build a Python distribution that installs a package into site-packages, and installs a script into wherever Python scripts go on the PATH. The Python Packaging User Guide covers this in its tutorial on building and distributing packages. See the Layout and Scripts sections, and the samples linked from there.
This will usually give you an installed layout something like this:
<...somewhere system/user/venv .../lib/pythonX.Y/site-packages>
app_name/
file1.py
file2.py
cli.py
__init__.py
<...somewhere.../bin/>
app_name
But, depending on how the user has chosen to install things, it could instead be an egg, or a zipped package, or a wheel, or anything else. You don't care, as long as your code works. In particular, your code can assume that app_name is an importable package.
Ideally, the app_name script on your path is an "entry-point" script (pip itself may be a good example on your system), ideally one built on the fly at install time. With setuptools, You can just specify which package it should import and which function it should call in that package, it will do everything else—making sure to shebang the Python actually used at install time, figuring out how to pkg_resources up the package and add it to the sys.path (not needed by default, but if you don't want it to be importable, you can make that work), and so on.
As mentioned in a comment from the original asker, python-commandline-bootstrap might help you put this solution together more quickly.
The alternative is to keep everything out of site-packages, and make the package specific to your app. In this case, what you basically want to do is:
- Install a directory that contains both the package (either as a directory, or zipped up) and the wrapper script.
- In the wrapper script, add
dirname(abspath(argv[0]))tosys.pathbefore theimport. - Symlink the wrapper script into some place on the user's
PATH.
In this case, you have to write the wrapper script manually, but then you don't need anything fancy this way.
But often, you don't really want an application to depend on the user having some specific version and setup of Python. You may want to use a tool like pyInstaller, py2exe, py2app, cx_Freeze, zc.buildout, etc. that does all of the above and more. They all do different things, all the way up to the extreme of building a Mac .app bundle directory with a custom, standalone, stripped Python framework and stdlib and a wrapper executable that embeds the framework.
Either way, you really don't want to call the package directory src. That means the package itself will be named src, which is not a great name. If your app is called spamifier, you want to see spamifier in your tracebacks, not src, right?
Directory structure of a command line app
I wrote a guide to creating and distributing CLI tools in Python and thought it might be appreciated here!
Command Line Application Frameworks?
Best way to make a CLI menu tree
Hello,
I'm writing a Python 3 command line app with argparse, following the Real Python guide. They suggest the following directory structure in their toy app:
hello_cli/ │ ├── hello_cli/ │ ├── __init__.py │ ├── __main__.py │ ├── cli.py │ └── model.py │ ├── tests/ │ ├── __init__.py │ ├── test_cli.py │ └── test_model.py │ ├── pyproject.toml ├── README.md └── requirements.txt
At one point in the process flow, my app will use subprocess to call two external executable files. One exe will generate a collection of run-specific files (representing a database). The other exe will compare a query against this database file set to generate a final results_file that will be further processed by the app. All of these files will be overwritten whenever the app is run.
Can someone tell me where these exes and temp files should be stored? I was thinking two more directories at the same level as tests and then store the exes in one and the run-specific files in the other (but I'm not sure if there's a standard way to store these). So, keeping with the original example template, something like:
Before run:
hello_cli/ │ ├── hello_cli/ │ ├── __init__.py │ ├── __main__.py │ ├── cli.py │ └── model.py │ ├── tests/ │ ├── __init__.py │ ├── test_cli.py │ └── test_model.py │ ├── executables/ │ ├── exe_1 │ └── exe_2 │ ├── temp_files/ │ ├── pyproject.toml ├── README.md └── requirements.txt
Which, after run, will become:
hello_cli/ │ ├── hello_cli/ │ ├── __init__.py │ ├── __main__.py │ ├── cli.py │ └── model.py │ ├── tests/ │ ├── __init__.py │ ├── test_cli.py │ └── test_model.py │ ├── executables/ │ ├── exe_1 │ └── exe_2 │ ├── temp_files/ │ ├── db_file_1 │ ├── db_file_2 │ │ ... │ ├── db_file_N │ └── results_file │ ├── pyproject.toml ├── README.md └── requirements.txt
What do you think?
Cheers!