Sure, but nox is the closer counterpart for in-venv-task definitions. List “sessions” with -l, pick specific sessions to run with -s.

import nox
from nox.sessions import Session

nox.options.reuse_existing_virtualenvs = True
APP_NAME = 'logging_strict'

@nox.session(python='3.12')
def mypy(session: Session):
    """Static type checker (in strict mode)"""
    session.install('-U', 'mypy', '.')
    session.run('mypy',  '-p', APP_NAME, *session.posargs)

Unfortunately it doesn’t currently do any parallel runs, but if anyone wants to track/encourage/contribute in that regard, see nox#544.

As someone’s new comments just brought me back to this post, I’ll point out that these days there’s another good option: uv run.

No, I don’t use GHA locally, but the actions are defined to run the same things that I do run locally (e.g. invoke nox). I try to keep the GHA-exclusive boilerplate to a minimum. Steps can be like:

- name: fetch code
  uses: actions/checkout@v4

- uses: actions/setup-python@v5
  with:
    allow-prereleases: true
    python-version: |
      3.13
      3.12
      3.11
      3.10
      3.9
      3.8
      3.7

- run: pipx install nox

- name: run ward tests in nox environment
  run: nox -s test test_without_toml combine_coverage --force-color
  env:
    PYTHONIOENCODING: utf-8

- name: upload coverage data
  uses: codecov/codecov-action@v4
  with:
    files: ./coverage.json
    token: ${{ secrets.CODECOV_TOKEN }}

Sometimes if I want a higher level interface to tasks that run nox or other things locally, I use taskipy to define them in my pyproject.toml, like:

[tool.taskipy.tasks]
fmt = "nox -s fmt"
lock = "nox -s lock"
test = "nox -s test test_without_toml typecheck -p 3.12"
docs = "nox -s render_readme render_api_docs"

If you choose to give Fedora a try, I recommend Ultramarine, which has more set up from the start, including their “Terrs” repository with more updated packages.

New discussion on Hacker News

New discussion of Uxn on Hacker News

Discussion on hacker news

• https://www.altap.cz/
• Files
• Double Commander
• Dolphin
• mucommander

In no particular order.

Ah yes you can tell by the post title:

best linux terminal emulator

Oh, is that #4948?

For me: Wezterm. It does pretty much everything. I don’t think Alacritty/Kitty etc. offer anything over it for my usage, and the developer is a pleasure to engage with.

Second place is Konsole – it does a lot, is easy to configure, and obviously integrates nicely with KDE apps.

Honorable mention is Extraterm, which has been working on cool features for a long time, and is now Qt based.

Just note that the comment was inaccurate, in that their weird encryption is indeed open source at least.

I’d say an important part of this calculator’s interaction model is doing something, getting a result, then doing something else to that result. That’s not too bad in the regular Python interpreter either.

For example, in Python:

>>> 5
5
>>> 4 + _
9
>>> 2 * _
18

In Stacker:

>>> 5
[5]
>>> 4 +
[9]
>>> 2 *
[18]

Does Hy have something like the Python interpreter’s _?

So it looks like a totally different data flow style, and (I think) geared toward writing then running programs, whereas Stacker is more for interactive stack-oriented calculator tasks.

I’ve never used Hy. Does it offer any concatenative-style interaction?

I suggest trying this one for Zsh, over the more common one: https://github.com/zdharma-continuum/fast-syntax-highlighting

As someone else said, setting less’ jump value is helpful.

Another tool I use, mostly for the zshall manpage, is https://github.com/kristopolous/mansnip

Thanks, yes, I use nox and github actions for automated environments and testing in my own projects, and tox instead of nox when it’s someone else’s project. But for ad hoc, local and interactive multiple environments, I don’t.

If it didn’t bring something more to the table, besides speed, no one would care

I’m literally saying its speed in certain operations makes an appreciable difference in my workflows, especially when operating on tens of venvs at a time. I don’t know why you want to fight me on my own experience.

I’m not telling anyone who doesn’t want to use uv to do so. Someone asked about motivation, and I shared mine.

The convention

That’s one convention. I don’t like it, I prefer to keep my venvs elsewhere. One reason is that it makes it simpler to maintain multiple venvs for a single project, using a different Python version for each, if I ever want to. It shouldn’t matter to anyone else, as it’s my environment, not some aspect of the shared repo. If I ever needed it there for some reason, I could always ln -s $VIRTUAL_ENV .venv.

Learn pyenv

I have used pyenv. It’s fine. These days I use mise instead, which I prefer. But neither of them dictate how I create and store venvs.

Shell scripts within Python packages is depreciated

I don’t understand if what you’re referencing relates to my comment.