[Wikitech-l] Re: Python requests broken by urllib3 version 2.x

> But now I'm curious about how conda enables running docker safely in production. :) It doesn't enable running docker, we just use packed conda envs instead of docker images. This only really works because we build and run the conda envs on the same OS. See conda-pack

[Wikitech-l] Re: Python requests broken by urllib3 version 2.x

> > > I'm working on an "Essential Tools for Managing Python Development > Environments > " > tutorial > Awesome! Did you consider conda envs? FWIW, we rely on conda envs >

[Wikitech-l] Re: Python requests broken by urllib3 version 2.x

> For Java, we run an instance of Archiva: https://archiva.wikimedia.org/ > It's not a perfect approach but I think we can and should move in that direction with all our other ecosystems Gitlab package registries may help us here! On Mon, May 8, 2023 at 8:59 AM Andrew Otto wrote: > > Tangent:

[Wikitech-l] Re: Python requests broken by urllib3 version 2.x

> Tangent: is it worthwhile to establish a consensus for best practices with package pinning and package management for Python projects in the Wikimedia ecosystem? Yes! That would be awesome. I have spent a lot of time floundering in this area trying to make decisions; it'd be nice if we had a good

[Wikitech-l] Re: Python requests broken by urllib3 version 2.x

> On 5. May 2023, at 17:30, Slavina Stefanova wrote: > >> Tangent: is it worthwhile to establish a consensus for best practices with >> package pinning and package management for Python projects in the Wikimedia >> ecosystem? When I last worked on a python project >> (https://wikitech.wikime

[Wikitech-l] Re: Python requests broken by urllib3 version 2.x

> > Tangent: is it worthwhile to establish a consensus for best practices with > package pinning and package management for Python projects in the Wikimedia > ecosystem? When I last worked on a python project ( > https://wikitech.wikimedia.org/wiki/Add_Link) I found it confusing that > we have so m

[Wikitech-l] Re: Python requests broken by urllib3 version 2.x

For Java, we run an instance of Archiva: https://archiva.wikimedia.org/ It's not a perfect approach but I think we can and should move in that direction with all our other ecosystems (python, Javascript, PHP). Our reduction in security-relevant surface area alone would be worth it. On Fri, May 5

[Wikitech-l] Re: Python requests broken by urllib3 version 2.x

Tangent: is it worthwhile to establish a consensus for best practices with package pinning and package management for Python projects in the Wikimedia ecosystem? When I last worked on a python project (https://wikitech.wikimedia.org/wiki/Add_Link) I found it confusing that we have so many diffe

[Wikitech-l] Re: Python requests broken by urllib3 version 2.x

Poetry is a modern lockfile-based packaging and dependency management tool worth looking into. It also supports exporting dependencies into a requirements.txt file, should you need that (nice if you want to containerize an app without bloating the image with Poetry, for instance). https://python-p

[Wikitech-l] Re: Python requests broken by urllib3 version 2.x

A word of warning: using `pip freeze` to populate requirements.txt can result in a hard to read (very long) file and other issues: https://medium.com/@tomagee/pip-freeze-requirements-txt-considered-harmful-f0bce66cf895 . *Sebastian Berlin* Utvecklare/*Developer* Wikimedia Sverige (WMSE) E-post/*E

[Wikitech-l] Re: Python requests broken by urllib3 version 2.x

You can also create an empty virtual env, install all requirements and then do pip freeze > requirements.txt That should take care of pinning Am Fr., 5. Mai 2023 um 13:11 Uhr schrieb Lucas Werkmeister < lucas.werkmeis...@wikimedia.de>: > For the general case of Python projects, I’d argue that a

[Wikitech-l] Re: Python requests broken by urllib3 version 2.x

For the general case of Python projects, I’d argue that a better solution is to adopt the lockfile pattern (package-lock.json, composer.lock, Cargo.lock, etc.) and pin *all* dependencies, and only update them when the new versions have been tested and are known to work. pip-tools