Harlequin: SQL IDE for Your Terminal

See my sibling response(s). Also this comment criticizing the solution in that link you gave me:

https://gist.github.com/saurabhshri/46e4069164b87a708b39d947...

requirements.txt is just a list of packages for pip. It doesn't even need to be called requirements.txt, it could be called poopoopeepee.txt. That name is just a convention.

You could do `for line in requirements.txt, pip install `. They are ostensibly the same. It is not a magical lockfile. It is unix. It is just a list if packages. If you are in a virtualenv, you will be fine.

either activate the venv,

    source venv_directory/bin/activate
    pip install -r requirements.txt

or, skip the convenience and use the binary directly:

    venv_directory/bin/pip install -r requirements.txt

virtualenv activation just sets the $PATH to refer to those binaries. you can use them directly.

the production deployment for my core python app lives in /srv/app, the venv lives in /srv/venv

To update packages on the system, it is as simple as

   cd /srv/app
   /srv/venv/bin/pip install -r requirements.txt

Then to invoke this with the correct runtime, it is as easy as

   /srv/venv/bin/gunicorn ...

In this example I am running the gunicorn application server. This is running the specific gunicorn version installed into my virtualenv.

The name `/srv/venv` is my decision. You can call that whatever you want and put it wherever you want. For instance, if you have two projects called application-foo and application-bar, you can have the following:

    /srv/application-foo/app - the codebase (ie, the github repo)
    /srv/application-foo/venv - the corresponding virtualenv
    /srv/application-bar/app
    /srv/application-bar/venv

Some people will even put their venv dir inside of their source tree and exclude it from git (add to .gitignore), but I do not like this approach because my deployments destroy the app dir and unzip the build into that location on each deploy.

I cannot speak for every python-based project (distinction from pip package) out there. A lot of people do not know what they are doing, open source is literally all the rope to hang yourself with. Anything is possible, and people without engineering experience will glue things together without understanding how they work.

If you are installing something via pip, then yes, you can create N virtualenvs and use them however you want. They are 100% isolated environments.

If you are using homebrew, apt-get, dnf/yum, arch etc... then those are going to obviously vary from distro to distro and that is outside the scope of this discussion.

I try to stick to Python's native tools as much as possible. Using a distribution package is going to cause issues, for sure. IE, don't install `apt-get install python-pil`, use a virtual environment and `pip install PIL`

> SQL Server and Oracle

Alright so first off, for 90% of SQL Server's existence, Microsoft was openly open-source-hostile, so give me a fucking break with this. Microsoft used to be way worse than even Apple about keeping everything in their ecosystem- at least Apple is built on BSD underpinnings and was therefore also always compatible with POSIX stuff.

Oracle... last I checked on that monstrosity it had about 20 different clients all written at different times for different use cases over the long course of Oracle's history. So, which of these 20 different clients should one write a TUI for?

Speaking for myself, it wasn't a "movement against application bloat" so much as a "frustrated response to these darn bloated applications." There wasn't anything ideological about it, I literally ran out of memory a few times when using VSCode. The important thing is that editing plain text works perfectly well in a terminal, whereas you need a modern GUI for most other business-related software.

I switched to emacs during the pandemic because of Zoom and Slack (along with my horrible browser habits). VSCode is pretty reasonable on resources compared to many Electron apps, and I slightly prefer it to emacs in terms of overall experience. But emacs is also good, and there were just too many Zoom calls where my computer ran out of memory, with VSCode having a glaringly high footprint. I think at the time its terminal emulator was either excessively inefficient, or it had a specific resource leak. So maybe things have gotten better, but I've stuck with emacs regardless.

These days I can let a few dozen unread tabs in Firefox fill in the extra ~1GB of memory VSCode was formerly occupying :)

It works for installing dependencies from Pip, so yes, unless that Python project is doing something bizarre that it shouldn't be doing.

It's functionally identical to node_modules or Ruby Bundler or Perl local::lib.

It's so weird to me that people continue to hate Python for a problem that literally every programming language has had since shared libraries were invented.