my_project/ ├── .vscode/ │ └── settings.json ├── src/ │ └── main.py ├── tests/ │ └── test_utils.py └── utils/ └── utils.py Whether or not IDE/editor-specific files should be included in version control (e.g. Git) is a somewhat hot topic, and I know your question had nothing to do with that, but I just thought I'd mention that in most cases it's best to .gitignore them. I'll get back to this specific case later. If following a flat project structure, src should be a package and named after the project. If not, src should only contain packages (usually only one), and you should have a pyproject.toml file in the repository root containing the necessary metadata and possibly other configuration options. By using packages you simplify your imports and paths a lot, making your code far easier to test. main.py is the script to be run with imports from the utils file/module utils should not be in the repository root if it relies on other code in the project. Similarly, main.py shouldn't depend on anything higher up the directory tree. For self-contained scripts (for example, something used to simplify build processes in CI pipelines) the convention I've used is a scripts directory with independent script files. Side note; utils is a fairly generic name, and often there's a better way to structure your program where you wouldn't need that. settings.json contains: { "python.testing.pytestArgs": [ "tests" ], "python.testing.unittestEnabled": false, "python.testing.pytestEnabled": true } Instead of configuring pytest in an IDE-specific file, I'd very much recommend doing at least most of it in pyproject.toml or pytest's own configuration file, as then it'd behave the same no matter how you run it. For example, in this case I'd move at least the test file location to them. If you need an example, you could consider this: https://github.com/Diapolo10/python-ms More on reddit.com

This question is best in r/learnpython Pytest specifically For pytest specifically, you should update your pytest.ini file and/or setup.cfg at the top of your repo and simply run py.test within your python virtual environment at the top of the repo. Hopefully you're using virtualenv or (better) vex. Ideally, you've also setup tox and potentially detox (ues a tox.ini or setup.cfg) so you can do more CI-like matrix testing against multiple environments. Tox also lets you build out environments for other things (like documentation). py.test (and tox or detox) will find your test files matched against test_* by default regardless of where the test files live. So you can structure your package with a top level tests folder or not -- whatever makes the most sense to you (and hopefully to whomever uses your code). By adding a __init__.py (not recommended) to your tests folder, it will get pulled into your package when its built. And in that scenario you can run tests on your target environment with a -m option, but I suspect you should really only run tests on your dev and qa environments (if you have both of those) and explicitly use pytest or tox. Command-lines generally I have two answers. I'm not sure which one you're actually looking for. Setup the script properly with a shebang. Add a console script to your setup.py First answer You might be looking to add this at the top of your file: #!/usr/bin/env python That will tell your bash shell to look for the default python in your environment and run it. Within a script, you'll want to add a few things, though: # !/usr/bin/env python # -*- coding: utf-8 -*- # file: hello.py def hello(): print('Hello!') if __name__ == '__main__': hello() This will tell the script to run hello only if it's in the 'main' environment within python...which is what the top level environment is when you start up the interpreter. You can check that with: $ python >>> print(__name__) __main__ Anything that falls under that __name__ == '__main__' line will only be executed from a top level python interpreter. The line will not be run during an import. Second answer The other option you may be looking for is a __main__.py and then adding a console script like so: entry_points = { 'console_scripts': [ 'command_line_name=package.__main__:function' ], } so if you did something like this: # file: hello_package/__main__.py def hello(): print('Hello!') and # file: setup.py from setuptools import setup ... setup( ... entry_points = { 'console_scripts': [ 'hello=hello_package.__main__:hello' ], } ... ) You could then run from your standard linux command-line: $ hello Hello! Command-line parsers Also, you'll want to think about how you write your command-line parser. Python comes with argparse but it's terribly obsolete at this point. Some later versions have integrated optparse, but while it's a better library than argparse the interface still leaves much room for improvement. Your best bet is to look at docopt and click. They're not really intended to be used together. The former provides a great way of specifying all of your command-line options at the top of your file within a docstring for that module. This makes it extremely easy to find the options for anyone looking at it later. And since you're using the docstring in the actual execution of the code, that also means that it will be kept up-to-date. click is the other option and provides a great decorator system. It's also modular enough that it can be used to produce more complex command-lines than docopt. But it's harder to know what the options are for the command-line at first glance, so learning/maintenance can be more difficult. I recommend this for smaller command-lines or command-lines that require multiple layers of commands (e.g. git). More on reddit.com

My first thought is that those files are going to end up installed in your package directory when you install it with pip or included in a wheel or however you package up your code. Why would you want to include tests in a 'deliverable' like that? More on reddit.com

3 tips from me: When you use typing everywhere then you are forcing yourself to omit the circular dependencies (we cannot have circular dependencies imports in python) between modules which is the easiest way to keep a very basic structure. Think of the modules hierarchy while structuring the python code. Which module is high level (e.g. dashboard, GUI) and which is low level (e.g. some utils module build upon a standard library). Always import a module that has a lower level of abstraction (or in other words, lower complexity) in the module with higher complexity. E.g. GUI module imports storage access module and not the other way around. More on reddit.com