Our great sponsors
-
not-a-package-manager
utilities to facilitate working with codebases that don't ascribe to normal package management paradigms, e.g. ML research code that can be cloned but not installed.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
the way I manage (2) is with a kind of DIY pipenv system i've come up with. i have a tool installed in my terminal called autoenv. when i navigate to a new directory, if there's a .env file in it, autoenv executes it. that's basically all autoenv does. I have a .env in my home folder that, among other things, activates my "master" venv. when I create a new project that I want to have its own venv, I just add a .env file to that folder to activate it. otherwise, the master venv is active whenever I roam around my filesystem, functionally serving as a default environment i reuse.
Another bespoke solution I use is napm ("not a package manager"), which allows me to reuse poorly structured git dependencies (I work with a lot of research code written by people who are researchers first and engineers second).