this post was submitted on 08 Aug 2024
12 points (92.9% liked)
Python
6327 readers
218 users here now
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
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I don't want to make the
venv
portable...I want to use the
gunicorn
that is installed in onevenv
accessible to othervenv
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 requireslibA-v1
and the gunicornvenv
useslibA-v2
, you're going to have a conflict at runtime.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 likebash -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 inbash
or inpython
- up to you.As I said, dirty dirty and honestly I'd just install
gunicorn
in everyvenv
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.Anti Commercial-AI license
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.htmlSharing 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 @[email protected] is looking for. Good shout.
Anti Commercial-AI license
Why? How many kilobytes of disk space are you going to save from that?