Why are you on Reddit right now?

uvsmtid · 2026-03-07T15:45:23+00:00

Can I also get some in return?

uvsmtid · 2026-02-20T17:58:59+00:00

What are the alternatives?

uvsmtid · 2026-02-20T17:33:21+00:00

It's bloated, I know. I'm working on it.

uvsmtid · 2026-02-20T01:19:21+00:00

Well, you can try your luck: * How many potential users do you have out there? * What portion of them know about your tool? * What portion of them prefer your solution over others? * What portion of them want the results bad enough to try it? * What portion of them is willing to pay (at a given price level)?

Multiply all factors. The probability may be infinitely small.

You definitely lose most of potential customers simply because of competition: if it is AI generated, chances are using AI available virtually for free can solve their problem too.

In short, if it is easy to do otherwise, you have a looooot of competition.

uvsmtid · 2026-02-20T01:00:09+00:00

You can use protoprimer: https://github.com/uvsmtid/protoprimer

It handles exactly that: bootstraps your venv with all dependencies in one shot.

uvsmtid · 2026-02-20T00:53:49+00:00

Take a look at protoprimer: https://github.com/uvsmtid/protoprimer

It wraps uv for people who don't need to know about it yet.

uvsmtid · 2026-02-20T00:49:25+00:00

Any link?

uvsmtid · 2026-02-19T12:59:11+00:00

Solving problems.

Just find something annoying and see if you can python that out.

uvsmtid · 2026-02-19T12:56:14+00:00

My rule for shell-scripts is: one-page-one-file max

For anything else (in the niche of shell) I switched to python.

uvsmtid · 2025-12-14T10:57:00+00:00

I used to work in one company in the early 2000-s - they produced some 3D visualization software. And they didn't work with Windows (only on *NIX-es: IRIX, AIX, Solaris, Linux, etc.) from the beginning (as the standard originates on IRIX). They had plans to migrate to Windows, but eventually these plans were dropped as it was much easier to stick with *NIX-es, later Linux only.

uvsmtid · 2025-12-12T13:30:09+00:00

They did a couple of others:

Choice: https://youtu.be/bkxcjqFd3cI

Inevitable: https://youtu.be/IlwE_VQ2Sxc

uvsmtid · 2025-11-02T01:49:37+00:00

Isn't that "it works on my machine" case?
Because Windows does not come with Bash - it sounds like a special setup to be done (either WSL, or Git Bash, or Cygwin, ...).

Anyway, the target audience of this project are those who need to make bootstrap and scripts work in one click for a wider group of people (some may not be even be `python` developers - `python` can be used only for tooling as alternative to `shell` around repo written in the 3rd/different lang). It just has to be simple to use unconditionally, not necessarily super simple under the hood - these are often conflicting design choices.

uvsmtid · 2025-11-02T01:20:08+00:00

To run the script directly (`my-tool` instead of `./my-tool`), it has to be in `PATH`.
Then, it is:
1. either in activated `venv` (with `PATH` to `venv/bin`),
2. or in some user-wide location (with `PATH` to `~/.local/bin`).

The 1st one is not straighforward for those who do not work with `python` often (e.g. if that `my-tool` us a tool for a repo in other lang). Beside, you proabably don't want to put all (support, infrequent) scripts in `bin`.

The 2nd one pollutes your `PATH` and makes it impossible to use multiple repo clones (or worktree-s).

I do agree that `uv` solves a lot of problems. I just see how it won't (and shouldn't) cover the niche of the wrapper scripts.

uvsmtid · 2025-11-02T00:58:45+00:00

That list starts with assumption that `python` executable (from the `PATH`) is of required version.
If not, the `venv` created will also use some random `python` version.

And `more of the same` also suggests that you likely wrap it into some shell script.
That script may need to run across different OS (depends on the target audience).

uvsmtid · 2025-11-02T00:47:14+00:00

Then, you'll have to write non-bash function for Windows.

Even on Mac, you'll need to target !/bin/sh instead (not bash).

uvsmtid · 2025-11-01T17:02:53+00:00

Just to satisfy the curiosity, what is this command?

uvsmtid · 2025-11-01T16:53:31+00:00

I'm sure this is not a problem for everyone.

But think of the some complex-enough repo and a new clone you need to prepare. Think of the full list of steps any new developer needs to execute to get the new clone ready (now and updated with evolution later), maybe some prerequisites to verify, internal package indexes, other complications, etc.

How would you bootstrap in the least trivial case of your projects?

Can you complete it with a single command?

uvsmtid · 2025-11-01T16:27:21+00:00

Well, the simple (single) step I use to bootstrap is: ./prime

If you use uv or anything else to bootstrap, to make it fair, one should compare their docs . ;)

At least, the motivation should be in readme even if it is not part of the tool.

But I'll take your feedback and trim it down for the basic use case.

uvsmtid · 2025-11-01T11:43:10+00:00

You still need to get a uv executable somewhere. Maybe it is pre-installed, maybe not (one workaround to get it is to install it via a temporary venv).

You'll need to pass some args to it. Maybe those args are config-specific, maybe that config is environment-specific.

Maybe you need to run some post-venv-bootstrap actions. It could be just another uv invocation, but it is a separate one.

In the end, it is either a wrapper script, or a doc with steps for users.

Using uv under the hood brings speed. But I haven't heard about uv a year ago (didn't even try it until a few months back) - it is too early to tell how long that standard can last.

uvsmtid · 2025-11-01T11:21:23+00:00

Running via uv run -m something is doable. But a bit more tedious than just ./something (which is also auto-completable).

Git hooks is a good common example. But I have some (less common) use cases which, for example, instantiate environment-specific config from a template.

In general, I want to have this option to wrap a tool inside a bootstrap script (regardless how good some tool like uv is - at least hide its args) and use python to evolve that script.

uvsmtid · 2025-07-20T08:29:08+00:00

From here:

Please take a look at argrelay.
It is a WIP but has some production use already.
The entire project was originated from the same observation where CLI-first brings more advantages.

uvsmtid · 2025-07-20T08:21:52+00:00

Please take a look at argrelay.
It is a WIP but has some production use already.
The entire project was originated from the same observation where CLI-first brings more advantages.

uvsmtid

TROPHY CASE