[HN Gopher] Harlequin: SQL IDE for Your Terminal
___________________________________________________________________
Harlequin: SQL IDE for Your Terminal
Author : jzombie
Score : 84 points
Date : 2024-01-05 18:20 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jcuenod wrote:
| Harlequin has been on my "to investigate" list since it popped up
| on hn a few weeks/months ago. I still need to experiment with it
| a bit more, but I had been thinking of building a some tragic
| equivalent to this, and now I don't have to :)
| jadbox wrote:
| The HN hive mind is amusing as I came here to get to comment
| this exact post. It looks really interesting, and I'm also
| tired of giving up so much memory for just a SQL GUI tool.
| graemep wrote:
| I have been looking for a nice SQL TUI and this looks like it.
| Will give it a try. Thank you.
| hans_castorp wrote:
| pspg is a pager intended to be used with SQL command line
| clients. It was originally created for Postgres (hence the
| name), but also works with MySQL and others
|
| https://github.com/okbob/pspg
| patja wrote:
| Suggestion: under "works with your database" consider naming the
| databases rather than only offering a list of icons.
|
| Also seems to be a bit of hubris to claim a SQL IDE "works with
| your database" when SQL Server and Oracle, two of the database
| products with the largest market share, are not supported (yet?)
| garciasn wrote:
| Agreed. I found the current connectors in their docs here:
| https://harlequin.sh/docs/adapters
|
| I'm pretty pumped to try this seeing BigQuery is supported.
| boomskats wrote:
| > SQL Server and Oracle, two of the database products with the
| largest market share
|
| Agree on the first point, but is 'market share' - a metric
| comparing commercial sales revenue which by definition excludes
| open source software, really that relevant when critiquing a
| tagline for a FOSS tool implicitly targeting FOSS databases at
| a time when FOSS dominates?
|
| If this wasn't an MIT licensed project without a single hint of
| a commercial offering I'd get it, but come on.
| chrsig wrote:
| It's relevant in that they're prolific databases, so there's
| a nontrivial chance that a user of one of them will:
|
| - stumble across the tool
|
| - read that it "works with their database"
|
| - hopefully read the actual list of supported databases
|
| - become disappointed to learn that it does not in fact work
| with their database
|
| In the case that hopes are not met, the user actually
| downloads the application and discovers the hard way that it
| does not work with their database.
|
| So market share does seem relevant to the frequency of
| disappointment though. Is it going to be a frequent enough
| occurrence to be worth spending any time doing anything
| about? I don't know.
| tconbeer wrote:
| Author here. If that disappointment fuels a half day of dev
| time, anyone who knows Python can just create their own
| adapter.
| pmarreck wrote:
| > 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?
| Koshkin wrote:
| > _give me a fucking break_
|
| No we won't :)
|
| https://pypi.org/project/pyodbc/
| tconbeer wrote:
| Fair enough (author here). I just launched support for any
| databases other than DuckDb and published a guide to create
| adapters for new dbs. I'm expecting the community to step up
| here, since I'd rather spend my time adding features to
| Harlequin. ODBC should be coming shortly. The hard part is
| honestly just having access to a DB server for testing.
| alberth wrote:
| Question: do people love TUI, because they love being in a
| terminal?
|
| Or ... is this a movement against application bloat, which has
| become all to common these days?
|
| EDIT: why the downvotes?
| sprash wrote:
| If you develop SQL you need to write code and view tables. A
| grid with monospace characters is perfectly suitable for that.
|
| But other than that, no, people don't love being in a terminal.
| It just happens that all open source portable toolkits like qt
| and gtk do not work via ssh and are in general total
| abominations for developers and users. The vt100 standard is 45
| years old and turned out to be the lowest common denominator to
| write GUIs for better or worse.
| alberth wrote:
| > _" if you develop SQL you need to write code and view
| tables ... [other tools] do not work via ssh"_
|
| Are you implying that people only write code inside of a
| terminal ssh session?
| greggyb wrote:
| I believe their next sentence took away the need to try to
| infer anything, and in fact made their point quite clear:
|
| > A grid with monospace characters is perfectly suitable
| for that.
| chrsig wrote:
| It doesn't seem like it to me. ISTM that they're implying
| that most sql tools have a gui component which isn't
| friendly to running remotely over an ssh session.
|
| I've personally never seen a good experience of display
| forwarding over ssh.
|
| Of course, most people and tools get around this by
| tunneling a connection to the database over ssh and running
| the GUI locally.
| ziftface wrote:
| I actually like being in the terminal for the most part. The
| vast majority of GUI applications are a huge disappointment.
| mongol wrote:
| > The vt100 standard is 45 years old and turned out to be the
| lowest common denominator to write GUIs for better or worse.
|
| I would say the web browser is the lowest common denominator
| tjohns wrote:
| That's assuming you can open up a port on a remote machine,
| which isn't always the case.
| sgarland wrote:
| Me. I love being in the terminal. Full-screen nvim with split
| buffers. If I want a terminal I can spawn it from inside nvim
| as a new buffer, or use my terminal emulator (kitty)'s native
| split functionality. I can do git actions without leaving
| nvim, too.
| TehShrike wrote:
| I'm not excited about it being a TUI, I'm just excited because
| it looks reasonable and I haven't found a macOS SQL client for
| writing queries that I was excited about yet
| dragonelite wrote:
| I like TUI because it usually works nicely with multiplexer
| like zellij or tmux. Open a new pane or tab where you can open
| a new set of TUI apps.
|
| Like have Helix or Nvim open, but you want to quickly check
| your database queries code changes. You can just open a new tab
| run the this sql IDE, fire off some queries check the result if
| it matches go back to coding new features. If not change the
| code, check queries again etc etc.
| nicklecompte wrote:
| 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 :)
| FusionX wrote:
| Another advantage is that TUI apps can be easily used over SSH.
| tconbeer wrote:
| I originally wrote this because sometimes a CLI or TUI is just
| super convenient. I used to use the DuckDB and Sqlite CLIs a
| lot, but was frustrated by their limitations, especially for
| doing data analysis work (my background).
| andrewl wrote:
| I do a lot of work with SQLite, and I do sometimes use one of
| the GUI clients (specifically sqlitebrowser.org). However, I
| mostly use the command line client that comes with SQLite, not
| because of how many features it has (not a lot) but because I
| use Bash and everything that comes with it, across various
| sessions managed with Tmux, as part of what I do with SQLite.
| It's the same reason I usually use Vim in a terminal session
| instead of the GUI version. Using the GUI version means
| stepping _away_ from a lot of my best tools.
| pmarreck wrote:
| Every time I notice something is a Python codebase I feel a
| letdown as it means it will likely break some other Python
| project from someone else I have on my dev machine which I may
| not have touched in a while but which I will find got silently
| broken when I most need it
|
| Especially if it's a nice TUI app like this looks
|
| EDIT: Guys, in my experience, virtual environments _do not fix
| this problem in all cases_. At least, not sufficiently for me
| (after getting used to Nix 's guarantees, for example). Not to
| mention, there's multiple ways/attempts at creating and working
| with virtual environments:
| https://twitter.com/pmarreck/status/1735363908515295253). See
| below comment.
| nicoco wrote:
| Install using pipx to avoid that. (or virtualenvs directly if
| you don't mind getting your hands dirty)
| pmarreck wrote:
| see my response to your sibling comment by whalesalad.
| sgarland wrote:
| While I do like pipx, and am a diehard Python fan, if the
| interpreter used to install the project changes, I still have
| to reinstall the project, which is annoying.
|
| I suppose I could get around that by installing a Python
| interpreter outside of brew, and only use that for packages.
| isp wrote:
| This is the problem that 'venv' (virtual environments) was
| designed to solve.
|
| You can run pip in an isolated virtual environment, in user
| mode (not as root) - see
| https://gist.github.com/saurabhshri/46e4069164b87a708b39d947...
| pmarreck wrote:
| See my sibling response(s). Also this comment criticizing the
| solution in that link you gave me:
|
| https://gist.github.com/saurabhshri/46e4069164b87a708b39d947.
| ..
| whalesalad wrote:
| every project you have should be in a virtual environment. it
| is not hard. https://docs.python.org/3.12/library/venv.html
| python -m venv ~/my-venvs/<name> source ~/my-
| venvs/name/bin/activate pip install <package>
|
| but stuff like this would usually get installed globally, and
| your projects would instead have a venv.
|
| personally my favorite tool is pyenv, which allows you to have
| many versions of python on your machine as well as many
| virtualenv (which are assigned to any version you have
| installed)
|
| then it is as simple as pyenv virtualenv
| <version> <name> pyenv virtualenv 3.11.1 xyz
|
| and to activate pyenv activate xyz
|
| this allows you to keep every project you have isolated not
| only to the packages required to run it, but also the python
| version required.
|
| I work on a handful of projects that run on 3.10, 3.11 and
| 3.12. Each has their own independent python version, and within
| that version they also have their own python packages (pip
| environment).
|
| At the end of the day these are simply directories on disk.
| calvinmorrison wrote:
| > every project you have should be in a virtual environment
|
| It's like ye-olden days. Now we can go back to static linking
| and bundling everything in jar files and call it a win!
| pmarreck wrote:
| Yeah. I've heard this same comment before in different forms
| from "Python apologists" about a dozen times. In practice
| it's still a lot of hair-pulling, because your entire comment
| assumes that EVERY Python project is already doing things
| exactly this way and hasn't screwed up a single part of it:
| https://twitter.com/pmarreck/status/1735363908515295253
|
| but also...
|
| > but stuff like this would usually get installed globally
|
| well, you just killed (apparently unknowingly?) your whole
| argument right there, because globals are bad and absolutely
| not project-specific and absolutely do cause compatibility
| issues between different Python projects
|
| If you ever come around to Nix, it takes care of this problem
| for good (as in, it _guarantees_ that you will _never_ have 2
| projects that step on each other), across every ecosystem,
| not just Python 's. Unfortunately, I don't see very many
| Python projects at all that contain a flake.nix file, which
| is a damn shame, because it would cause people like me to
| hate Python just a tiny bit less
| whalesalad wrote:
| Hair pulling? It's the most barebones unix thing you can
| imagine. If you understand unix principles, you can use
| virtual environments and python.
|
| It _used_ to be hard. A global site-packages or dist-
| packages dir is hard. Conda and all those tools make it
| worse.
|
| A virtualenv is a directory. It contains a copy of Python
| and everything needed.
|
| You don't even need to activate it. You can simply use the
| binaries that exist in those directories.
|
| It's literally this simple: $ python -m
| venv pmarreck $ pmarreck/bin/python --version
| Python 3.10.12 $ pmarreck/bin/pip install harlequin
| Collecting harlequin Downloading
| harlequin-1.8.0-py3-none-any.whl (61 kB)
| ---------------------------------------- 61.5/61.5 kB 1.2
| MB/s eta 0:00:00 ... Successfully installed
| MarkupSafe-2.1.3 click-8.1.7 duckdb-0.9.2 harlequin-1.8.0
| jinja2-3.1.2 linkify-it-py-2.0.2 markdown-it-py-3.0.0 mdit-
| py-plugins-0.4.0 mdurl-0.1.2 numpy-1.26.3
| platformdirs-3.11.0 prompt_toolkit-3.0.36 pyarrow-14.0.2
| pygments-2.17.2 pyperclip-1.8.2 questionary-2.0.1
| rich-13.7.0 rich-click-1.7.3 shandy-sqlfmt-0.21.1
| textual-0.46.0 textual-fastdatatable-0.5.0 textual-
| textarea-0.9.5 tomli-2.0.1 tomlkit-0.12.3 tqdm-4.66.1 tree-
| sitter-0.20.4 tree_sitter_languages-1.9.1 typing-
| extensions-4.9.0 uc-micro-py-1.0.2 wcwidth-0.2.12
| $ pmarreck/bin/harlequin
|
| Boom, the tool launched immediately. No conflicts with
| anything else. When I am done, `rm -rf ~/pmarreck`, done.
|
| I did all of this in my home directory.
|
| It literally cannot get easier than this.
| pmarreck wrote:
| And this works with _every existing Python project_ out
| there? What about `requirements.txt` projects?
| whalesalad wrote:
| 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
| <line>`. 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`
| pmarreck wrote:
| alright, I will bookmark this and try this next time I
| want to play with a python project.
|
| OK, how would I include all of these under the same PATH
| regime?
|
| So for example say I want to run this project from a
| commandline location elsewhere... I'd only be able to
| have one venv activated at the same time in the same
| session, right?
|
| I guess that's part of my issue with this. I want to be
| able to access 10 different Python projects' commands
| from the same command line at any time.
| whalesalad wrote:
| To access 10 different commands at the same time, that is
| tricky but definitely doable.
|
| First thing that comes to mind, you can use aliases.
|
| To keep it simple, lets use 3 examples instead of 10:
| harlequin (this project), pgcli (https://www.pgcli.com/)
| and httpx (https://www.python-httpx.org/)
|
| Setup a main home for all your venvs:
| cd ~ mkdir venvs
|
| Go into this dir, and create your venvs and install the
| packages cd venvs python -m
| venv harlequin ~/venvs/harlequin/bin/pip install
| harlequin
|
| Now this binary is available at $
| ~/venvs/harlequin/bin/harlequin
|
| Repeat for the rest cd ~/venvs
| python -m venv pgcli ~/venvs/pgcli/bin/pip
| install pgcli cd ~/venvs python -m
| venv httpx ~/venvs/pgcli/bin/pip install httpx
|
| Wash, rinse, repeat. Now you have all these binaries
| available and can alias them alias
| harlequin="~/venvs/harlequin/bin/harlequin" alias
| pgcli="~/venvs/pgcli/bin/pgcli" alias
| httpx="~/venvs/httpx/bin/httpx"
|
| This is a pain in the ass though and usually simple CLI
| tools like this do not collide with each other. So that
| is why I say install globally, or install into your
| "global junk drawer" virtualenv.
|
| Meanwhile, for actual projects that you are developing
| on, those would have their own isolated venv.
|
| I have a junk drawer venv where I install tools like
| this. If something goes wrong, it is as simple as rm -rf
| the venv and make a new one. And then I have isolated
| ones for each of the actual systems I maintain. Again, I
| use pyenv for this to make it a little easier to manage
| in conjunction with their specific python versions such
| that I do not ever interact with my distribution's
| Python. This is cross platform so it works across mac,
| linux etc. Very easy workflow, isolated, safe, can get
| blown away and recreated in a heartbeat.
| nerdponx wrote:
| 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.
| nerdponx wrote:
| Your Tweet shows that you don't actually know what these
| tools do. There's not much overlap in functionality between
| Pyenv, Tox, and Poetry, for example.
|
| Also, nobody active in the Python community will argue that
| there's 1 correct way to do packaging. That's a serious
| straw man.
|
| Fortunately, none of those tools you mentioned other than
| venv are actually required to _run_ Python applications,
| and there are in fact exactly 2 recommended ways to install
| Python applications:
|
| 1) Use your system's package manager
|
| 2) Use a venv, either manually (as shown in the sibling
| comment) or using the Pipx tool, which just creates venvs
| for you.
|
| All of the other tools you mentioned (except for Pyenv)
| represent ~20 years of active development and iteration on
| how to manage projects and build packages for distribution,
| and end-users shouldn't even have to be aware of their
| existence. And Pyenv is just Rbenv but for Python.
|
| As I've pointed out elsewhere, this is exactly the same
| situation as with literally every other programming
| language that doesn't generate standalone executables, and
| is even a problem with those that do, if they rely on
| dynamic linking. The special ire towards Python in this
| case is neither warranted nor valid.
|
| Your _pinned post_ on Twitter is predicated on double
| standards and lack of basic understanding of the tools you
| 're criticizing. I'm not sure that's a good way to
| represent oneself.
| jzombie wrote:
| I made a simple CLI wrapper that automates this, like Poetry
| does, except my wrapper uses pip.
|
| https://github.com/jzombie/pipper
| nerdponx wrote:
| Have you seen Pipx or its predecessor Pipsi?
|
| Although your tool looks more like Virtualenvwrapper.
|
| It's good to have other options of course (and yours looks
| nice), but it's also good to at least make a case for
| improvement over what's already out there.
| jzombie wrote:
| Thank you.
|
| I have, actually (though not Pipsi). Some others have
| commented on that and lead me to them.
|
| Part of the "fun" of it was just doing it, I guess, and
| knowing exactly what went into it. Just a few lines of
| Bash, really.
| billowycoat wrote:
| This isn't an issue if you use virtual environments. See also
| pipx for installing isolated Python apps.
| pmarreck wrote:
| See my sibling response(s).
| seanw444 wrote:
| The horizontal scroll animation on the query results table is
| fascinating. Never seen animations like that in a TUI app.
| billowycoat wrote:
| https://textual.textualize.io/
| neverartful wrote:
| That's impressive! Anyone know if there are similar libraries
| available for other languages?
| ChrisArchitect wrote:
| https://harlequin.sh/
|
| There was a Show HN: from the author and this thread and
| discussion last year:
|
| https://news.ycombinator.com/item?id=37588526
| tconbeer wrote:
| Author here. Thanks for more love for Harlequin. I'll be checking
| back and responding to feedback and questions for the next few
| hours.
| alberth wrote:
| Looks super impression. Congrats.
|
| A few questions ...
|
| a. what caused you to start working this?
|
| b. any particular reason why you chose to implement it the way
| you did (e.g. I see you use Python + Textual as opposed to
| something like https://charm.sh/libs/)
|
| c. any major functionality you feel it's missing?
|
| d. any limitations (e.g. doesn't work with Oracle?)
|
| e. any reason why someone should _not_ use it?
|
| Thanks in advance.
| diazc wrote:
| There are also other interesting collection of TUI terminal tools
| like harlequin here as well:
|
| https://terminaltrove.com/
|
| harlequin is also featured there as a tool of the week on that
| site.
___________________________________________________________________
(page generated 2024-01-05 23:00 UTC)