pex

. The nicest thing about Pants is that it builds pex files (github.com/pantsbuild/pex) which are executable zip files that ship all of your dependencies except the Python interpreter and shared objects. I'm still not very satisfied with this solution, and it's still far, far worse than Go's dependency management and packaging model, but it's a dramatic improvement over Pipenv, virtualenv, etc (gives us both reproducibility and performance).

x. Your deployment target still needs the right version of the Python interpreter and .so files that your dependencies might link against. Personally, I've found that Go solves most/all Python issues without introducing too many of its own--and anyone writing Python (sans mypy) doesn't get to chastise Go for lacking generics! :)

. Or add the directory containing "python.exe", and its sibling "Scripts" directory to the OS system PATH manually (check a tutorial on that). Restart the console. Also, unrelated, but use a better console. cmd.exe sucks. cmder (https://cmder.net/) is a nice alternative. Then, don't use the Python command on Windows. Use the "py -x.y" command. It will let you choose which version of Python you call. So "py -2.7" calls python 2.7 (if installed) and "py -3.6" calls Python 3.6. Every time you see a tutorial on Python telling you to do "python this", replace it mentally with "py -x.y". UNIXES (mac, linux, etc): Python is suffixed. Don't just call "python". Call pythonX.Y. E.G: python2.7 to run python 2.7 and python3.6 to run Python 3.6. Every time you see a tutorial on Python tell you to do "python this", replace it mentally with "pythonX.Y". Not PythonX. Not "python2" or "python3". Insist on being precise: python2.7 or python3.5. LINUX: pip and virtualenv are often NOT installed with Python, because of packaging policies. Install it with your package manager for each version of Python. E.G: "yum install python3.6-pip" or "apt install python3.6-venv". FINALLY, FOR ANY OS: Use "-m". Don't call "pip", but "python -m pip". Don't call "venv", but "python -m venv". Don't call poetry but "python -m poetry." Which, if you follow the previous advices, will lead to things like "python3.6 -m pip" or "py -3.6 -m pip". Replace it mentally in tutorials, including this one. This will solve all PATH problems (no .bashrc or windows PATH fiddling :)) and will force you to tell which python version you use it with. It's a good thing. In any case, __use a virtualenv as soon as you can__. Use virtualenv for everything. One per project. One for testing. One for fun. They are cheap. Abuse them. In the virtualenv you can discard all the above advices: you can call "python" without any "py -xy" or suffixes, and you can call "pip" or "poetry" without "-m". Because the PATH is set correctly, and the default version of Python is the one you want. But there are some tools you will first install outside of venv, such as pew, poetry, etc. For those, use "-m" AND "--user". E.G: "python -m pip install poetry --user" "python -m poetry init" This solves PATH problems, python version problems, doesn't require admin rights and avoid messing with system packages. Do NOT use "sudo pip" or "sudo easy_install". 2 - Using requirements.txt You know the "pip install stuff", "pip freeze > requirements.txt", "pip install -r requirements.txt" ? It's fine. Don't be ashamed of it. It works, it's easy. I still use it when I want to make a quick prototype, or just a script. As a bonus, you can bundle a script and all it's dependencies with a tool named "pex" (https://github.com/pantsbuild/pex): pex . -r requirements.txt -o resulting_bundle.pex --python pythonX.Y -c your_script.py -f dist --disable-cache It's awesome, and allows you to use as many 3rd party dependencies as you want in quick script. Pex it, send it, "python resulting_bundle.pex" and it runs :) 3 - Using Setup.cfg At some point you may want to package your script, and distribute it to the world. Or maybe just make it pip installable from your git repo. Let's say you have this layout for your project: root_project_dir/ ├── your_package ├── README.md Turn it into: root_project_dir/ ├── your_package ├── README.md ├── setup.cfg ├── setup.py And you are done. Setup.py needs only one line, it's basically just a way to call setuptools to do the job (it replaces the poetry or pipenv command in a way): from setuptools import setup; setup() Setup.cfg will contain the metadata of your package (like a package.json or a pyproject.toml file): [metadata] name = your_package version = attr: your_package.__version__ description = What does it do ? long_description = file: README.md long_description_content_type = text/md author = You author_email = foo@bar.com url = https://stuff.com classifiers = # not mandatory but the full list is here: https://pypi.org/pypi?%3Aaction=list_classifiers Intended Audience :: Developers License :: OSI Approved :: MIT License Programming Language :: Python :: 3.5 Programming Language :: Python :: 3.6 Programming Language :: Python :: 3.7 Topic :: Software Development :: Libraries [options] packages = your_package install_requires = requests>=0.13 # or whatever [options.package_data] * = *.txt, *.rst hello = *.msg [options.extras_require] dev = pytest; jupyter # stuff you use for dev [options.package_data] # non python file you want to include * = *.jpg You can find all the fields available in the setup.cfg here: https://setuptools.readthedocs.io/en/latest/setuptools.html#... Setup.cfg has been supported for 2 years now. It's supported by pip, tox, all the legacy infrastructures. Now, during dev you can do: "pip install -e root_project_dir". This will install your package, but the "-e" option will make it work in "dev mode", which allow you to import it, and see modifications you did to the code without reinstalling it every time. "setup.py develop" works too. If you publish it on github, you can now install your package doing: pip install git+https://github.com/path/to/git/repo.git You can also create a wheel out of it doing: python setup.py bdist_wheel The wheel will be in the "dist" dir. Anybody can then "pip install your_package.whl" to install it. Mail it, upload it on an ftp, slack it... If you want to upload it on pypi, create an account on the site, then "pip install twine" so you can do: twine upload dist/* Read the twine doc though, it's worth it: https://pypi.org/project/twine/ You could use "python setup.py bdist_wheel upload" instead of twine. It will work, but it's deprecated. 4 - Using pew Pew (https://github.com/berdario/pew#usage) is an alternative to venv, poetry, virtualenvwrapper and pipenv. It does very little. "pew new env_name --python python3.X" Creates the virtualenv. "pew workon env_name" Activates it. And optionally moves you to a directory of your choice. That's all. It's just a way to make managing virtualenv easier. Use pip as usual. You can know where your virtualenv has been created by looking up the $VIRTUAL_ENV var. This is especially useful for configuring your IDE, although I tend to just type "which python" on unix, and "where python" on Windows. 5 - Using poetry Now, if you need more reliability, poetry enters the game. Poetry will manage the virtualenv for you, will install packages in it automatically, will check all dependencies in a fast and reliable way (better than pip), creates a lock file AND update your package metadata file. I'm not going to enter into details on how this work, it's a great tool, with a good doc: https://github.com/sdispater/poetry You don't need to start with poetry. You can always migrate to it later. Most of my projects do the "requirements.txt" => "setup.cfg" migration at some point. Some of them move to poetry if I need the extra professionalism it provides. The problem with poetry is that it's only compatible with poetry. It uses the pyproject.toml format, which is supposedly standard now, but is unfinished. Because of this: any tool using it, including poetry, actually stores most data in custom proprietary fields in the file :( Also, it's not compatible with setuptools, which many infrastructures and tutorials assume. So you'll have to adapt to it. That being said, it's a serious and robust tool.

to /opt or /usr elsewhere. The way to bundle it properly is to actually use two rpm packages linked together by rpm dependency. One for the app and the other for the deployment configuration. The reason is you only have one executable, but many possible versions of deploying it. Ie. depending on environment (dev, staging, prod) or you just simply want to run the same app in parallel with different configuration. eg. one rpm package for the app executable and statix files my_app_exe-2.0-1.noarch.rpm and many othe related config rpms my_app_dev-1.2-1.noarch.rpm (depends on my_app_exe > 2.0) my_app_prod-3.0-1.noarch.rpm (depends on my_app_exe == 2.0) You then install only the deployment packages and rpm system fetches the dependencies for you automatically. There are other mature places who use similar techniques for deployments, for example [4]. All of this then can be wrapped in even higher level of packaging, namely Docker. [1] https://github.com/pantsbuild/pex [2] https://code.fb.com/data-infrastructure/xars-a-more-efficien... [3] https://github.com/jordansissel/fpm [4] https://hynek.me/articles/python-app-deployment-with-native-...