If A_WebApp is truly the python file and app is some python symbol then you should be able to make gunicorn in another venv and call your script as such:
path/to/venv/bin/python gunicorn A_Web_App:app
Python
Welcome to the Python community on the programming.dev Lemmy instance!
π Events
Past
November 2023
- PyCon Ireland 2023, 11-12th
- PyData Tel Aviv 2023 14th
October 2023
- PyConES Canarias 2023, 6-8th
- DjangoCon US 2023, 16-20th (!django π¬)
July 2023
- PyDelhi Meetup, 2nd
- PyCon Israel, 4-5th
- DFW Pythoneers, 6th
- Django Girls Abraka, 6-7th
- SciPy 2023 10-16th, Austin
- IndyPy, 11th
- Leipzig Python User Group, 11th
- Austin Python, 12th
- EuroPython 2023, 17-23rd
- Austin Python: Evening of Coding, 18th
- PyHEP.dev 2023 - "Python in HEP" Developer's Workshop, 25th
August 2023
- PyLadies Dublin, 15th
- EuroSciPy 2023, 14-18th
September 2023
- PyData Amsterdam, 14-16th
- PyCon UK, 22nd - 25th
π Python project:
- Python
- Documentation
- News & Blog
- Python Planet blog aggregator
π Python Community:
- #python IRC for general questions
- #python-dev IRC for CPython developers
- PySlackers Slack channel
- Python Discord server
- Python Weekly newsletters
- Mailing lists
- Forum
β¨ Python Ecosystem:
π Fediverse
Communities
- #python on Mastodon
- c/django on programming.dev
- c/pythorhead on lemmy.dbzer0.com
Projects
- PythΓΆrhead: a Python library for interacting with Lemmy
- Plemmy: a Python package for accessing the Lemmy API
- pylemmy pylemmy enables simple access to Lemmy's API with Python
- mastodon.py, a Python wrapper for the Mastodon API
Feeds
Thank you ! it works !
Actually this is working :
path/to/venv/bin/gunicorn A_Web_App:app
Some other poster, claim it's dirty.. but which problems could it generate ? (if any)
Thanks all !!!!
I don't think it's dirty if you manage your requirements across these environments with care, but I'd ask for what they mean
It's possible to make the venv portable, versionize it, archive it and deploy at boot the latest version. It's architecture dependent though, so if you deploy on multiple archs, you will need to build for each.
Edit: gunicorn is part of the venv. All you need to do after deploying gunicorn is activating the venv and running your server.
You can also have the archive tun through several vulnerability checkers.
I don't want to make the venv
portable...
I want to use the gunicorn
that is installed in one venv
accessible to other venv
I don't think that's possible without some dirty, dirty hacks i.e adding the right paths from the other venv
to your running process. Do you want dirty hacks? Because that's just asking for trouble. If you have an application that requires libA-v1
and the gunicorn venv
uses libA-v2
, you're going to have a conflict at runtime.
I supposes that
gunicorn
is a shell program ?
source ./bin/activate
which gunicorn # outputs the path to gunicorn
less `which gunicorn` # reads gunicorn
gunicorn
takes a module and a module name with a variable name. Modules are found by searching in specific paths. You can add to that search path by modifying PYTHONPATH. How it works is explained here (quite wordy).
To know which path to add to PYTHONPATH
, you can either read .bin/activate
and figure it out, or run something like bash -c "source ./bin/activate ; env"
and it'll list all the environment variables. You can then expand (not replace) the environment variables of the current environment with those of the other environment - either in bash
or in python
- up to you.
As I said, dirty dirty and honestly I'd just install gunicorn
in every venv
then you're done with it. But if you really want to, try what I explained and see how it works for you. It's good to experiment and find out first hand.
Wouldn't enabling the --system-site-packages
flag during venv creation do exactly what the OP wants, provided that gunicorn is installed as a system package (e.g. with the distro's package manager)? https://docs.python.org/3/library/venv.html
Sharing packages between venvs would be a dirty trick indeed; though sharing with system-site-packages
should be fine, AFAIK.
Hadn't considered that. It might be the solution @SpongeB0B@programming.dev is looking for. Good shout.
Why? How many kilobytes of disk space are you going to save from that?
Use pip to install pipx, use pipx to install gunicorn to make it available globally. Pipx is meant to install applications as it will install each in their own venv, whereas pip will install them in a single global env.
Makes sure gunicorn isn't installed in your venvs, so when you run them, they'll use the pipx installed one.
I wouldn't recommend it. Installing Python packages not in a venv is asking for trouble. Why do you care anyway?