pip and venvs on Debian (was: Terminal Emulator)
Alan Gauld via Python-list writes: > On 18/05/2024 19:12, Piergiorgio Sartor via Python-list wrote: > > >> So venvs make managing all that pretty convenient. Dunno why everybody's > >> so down on venvs... > > Not so much down on them, they are just one extra step that's > mostly not needed(in my use case) Years ago, I used to have trouble with pip install --user on Debian -- sometimes things would end up under .local, sometimes in other places that I've forgotten. So I reluctantly started using venvs. And you know, they work fine. I have one master venv that I created with python3 -m venv --system-site-packages ~/pythonenv/envname and I activate that automatically when I log in, so when I need to install anything that Debian doesn't package, I just pip install it (no --user or --break-system-packages needed) and it installs to that venv. Every so often I need to regenerate it (like when Debian updates the system Python version) but that's easy to do: I don't try to duplicate what's installed there, I just delete the old venv, create a new one and then pip install packages as needed. I have a few special venvs (without --system-site-packages) for specific purposes, but most of the time I'm just using my default venv and it's all pretty transparent and automatic. I know this isn't the usual pythonista model of "you should have a zillion different venvs, one for each program you use, and never use system Python packages", but it works well for me: my pip installed packages are all in a predictable place, and I get security updates for all the software Debian *does* package. That's my biggest beef with pip, the lack of an easy way to update everything at once, and it's the reason I prefer Debian packages when available. ...Akkana -- https://mail.python.org/mailman/listinfo/python-list
Re: Question about garbage collection
I wrote: > > Also be warned that some modules (particularly if they're based on > > libraries not written in Python) might not garbage collect, so you may need > > to use other methods of cleaning up after those objects. Chris Angelico writes: > Got any examples of that? The big one for me was gdk-pixbuf, part of GTK. When you do something like gtk.gdk.pixbuf_new_from_file(), there's a Python object that gets created, but there's also the underlying C code that allocates memory for the pixbuf. When the object went out of scope, the Python object was automatically garbage collected, but the pixbuf data leaked. Calling gc.collect() caused the pixbuf data to be garbage collected too. There used to be a post explaining this on the pygtk mailing list: the link was http://www.daa.com.au/pipermail/pygtk/2003-December/006499.html but that page is gone now and I can't seem to find any other archives of that list (it's not on archive.org either). And this was from GTK2; I never checked whether the extra gc.collect() is still necessary in GTK3, but I figure leaving it in doesn't hurt anything. I use pixbufs in a tiled map application, so there are a lot of small pixbufs being repeatedly read and then deallocated. ...Akkana -- https://mail.python.org/mailman/listinfo/python-list
Re: Question about garbage collection
> Frank Millman wrote at 2024-1-15 15:51 +0200: > >I have read that one should not have to worry about garbage collection > >in modern versions of Python - it 'just works'. Dieter Maurer via Python-list writes: > There are still some isolated cases when not all objects > in an unreachable cycle are destroyed > (see e.g. step 2 of > "https://devguide.python.org/internals/garbage-collector/index.html#destroying-unreachable-objects";). Also be warned that some modules (particularly if they're based on libraries not written in Python) might not garbage collect, so you may need to use other methods of cleaning up after those objects. ...Akkana -- https://mail.python.org/mailman/listinfo/python-list
