Spiritus

CLIs have to be distributed. Also have to be kept up to date. An MCP doesn't t have to concern itself with backwards compatibility and can be changed willy nilly since it's essentially always up to date.

It's also easier to manage for non-tech people. Try telling the people over at HR or finance to install a CLI.

Not available in Business or? I only see SSH connections in Desktop app and only cloud environments in the iOS app.

Curious why? I'm considering doing the opposite since I have to pay for iCloud anyway.

I think you're mixing up try blocks with the old try! macro.

Unless you're looking for a specific video or trend, don't search. Just scroll.

I'm fairly sure it's Discourse[1]. They switched to it quite recently.

[1] https://www.discourse.org

It might be worth excluding certain directories from Spotlight to prevent it from indexing node_modules etc which tend to be massive but mostly useless from a Spotlight search perspective.

You can't. But is that possible with any programming language specific package manager? How would that even work given that every flavour of OS/distro have their own way of providing gfortran?

Well we're almost there I think. You can define dependencies and other metadata in pyproject.toml nowadays:

https://setuptools.pypa.io/en/latest/userguide/pyproject_con...

Nimble is Nim's build tool so that's already taken.

Get an e-sim

Tilaa[1]. They also recently launched a managed database service[2] (beta).

[1] https://www.tilaa.com/ [2] https://www.tilaa.com/en/blog/tilaa-cloud-database-beta-is-l...

I've actually moved from direnv to shadowenv[1]. It's more powerful since it's using a Lisp dialect called Shadowlisp that lets you easily do things like append/prepend to $PATH, expand paths and other common actions.

[1] https://shopify.github.io/shadowenv/

> I suspect you are fighting the tide of common practice in the Python community.

I hope not!

> Sorting module- and from-imports separately also makes it much easier for many people to visually scan a block of imports.

For me it's the opposite. My brain skips over the irrelevant parts (i.e. import/from). Not moving the import also produces better git diffs

For me µsort is a non-starter since it doesn't ignore the import/from part when sorting lexicographically. So when an import changes from `import foo` to `from foo import bar` (and vice versa), the import is moved. Sorting should start at the package name, nothing else.

Python 2 is available from the https://github.com/lithammer/homebrew-deadsnakes Homebrew tap.

He's meant to play in the Australian Open, but his visa was revoked because he isn't vaccinated (it has been reinstated now though). So this is mostly just a joke since the opponent is a koala and the ball is the corona virus.

https://www.cbssports.com/tennis/news/australian-open-2022-n...

Pyright is open source (MIT)

It's likely because of this (custom Postgres client, request pipelining and not doing sync/commit after each query):

> [Multiple Queries] This is the first test where Just(js) has quite a big lead. This is likely due to the fact it is using a custom postgres client written in Javascript and taking full advantage of pipelining of requests. It also avoids sending a Sync/Commit on every query. As far as I am aware this is within the rules but will be happy to make changes to sync on every query if it is not.

https://just.billywhizz.io/blog/on-javascript-performance-01...

The author wrote a blog post about it: https://just.billywhizz.io/blog/on-javascript-performance-01...

Then `HOMEBREW_NO_AUTO_UPDATE` is probably for you.

> If set, do not automatically update before running brew install, brew upgrade or brew tap.

The “py” command?

That sounds like a Debian issue though. Or are you suggesting that Python (and by extension Pip) should align their support cycle with Linux distros?

Probably because Python 3.5 was EOL’d last year and 3.4 two years ago.

https://endoflife.date/python

Not sure about “0” but https://theartofpostgresql.com is a good book.

> [...] from time to time I need to write a script or use a popular python library like pygments and I used to hate having to do anything with python because of how difficult it seemed to install anything

Not sure I understand why you're having so much trouble. It's literally two commands:

    $ python3 -m venv venv  # Create virtualenv
    $ ./venv/bin/pip install pygments

However! One unfortunate thing with this is that `python3 -m venv` doesn't include the 'wheel' package in the virtualenv out-of-the-box. So it's often a good idea to install/upgrade pip, setuptools and wheel after creating the virtualenv:

    $ ./venv/bin/pip install -U pip setuptools wheel

Note that this just a draft/proposal. And there's heavy activity on the mailing list.

With that said, this has been suggested and discussed many times in the past. I imagine this will be as controversial as the walrus operator[1] was.

[1] https://www.python.org/dev/peps/pep-0572/

The idea is to filter so that it only shows Python. Not to compare with other languages.

Funny how in the TechEmpower Web Framework Benchmarks[1], the async frameworks are basically destroying their sync counterparts.

[1] https://www.techempower.com/benchmarks/

Yes, I was genuinely asking. I'm very familiar with how the Python ecosystem works (I've been using it professionally for the past 8 years or so), and I disagree with your assessment. At least not when comparing to other dynamic languages.

> Those libraries are installed by Pip... somewhere on your system.

They go into your virtualenv.

> And then Python has to find it somehow at runtime.

If you use a virtualenv, this works 99.9% of the time.

> That relies on environment variables being set correctly

What environment variables? Just use `./venv/bin/python` directly without environment variables.

> a huge mess even before you consider things like virtualenv

There's nothing to consider, always use a virtualenv. It's the same for thing for Node, except it implicitly handles it for you.

> and the fact that non-Linux systems usually have multiple copies of Python installed (and Python 2 and 3!).

How is that a problem? Just pick the interpreter you want to use when creating the virtualenv:

    virtualenv -p /usr/bin/python2 venv
    virtualenv -p python3 venv
    virtualenv -p python3.7 venv

> Consider the alternative: Go compiles programs to a single statically linked executable with no dependencies. You literally just copy one file to your target machine and run it. It basically can't fail. That's part of the reason Go is so popular for server stuff.

I agree that Go got it mostly right and it just works, except for that fact that it didn't even have a package manager for like 10 years so pinning dependencies was impossible unless you forked repositories.

> Even JavaScript - for all the hate node_modules gets for being enormous, at least it works reliably!

In what way is Python + virtualenv + requirements.txt less reliable?