Rendered at 13:50:15 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
unqueued 10 hours ago [-]
FYI A submodule doesn't have to use a gitfile and a corresponding `$GIT_DIR/modules/<name>` and there are good reasons not to. As long as the submodule has a '.git' it can be a symlink, or regular .git directory for a self contained embedded repo. You can still use the same gitlink in the parent repo representing it's commit id and git will still manage it.
If I have a 20GB submodule I'd usually just do a `git clone <url> <path> && git submodule add <path>` and it will be treated the same by git. But now I can just delete it and it's purged. And it is more portable less fragile in some ways because it's not de-referencing a gitfile. I prefer my repos to be more bottom-heavy and to not clog my modules folder.
I have a rough script that's the inverse of `git submodule absorbgitdirs` but it's a bit fragile.
It would be cool if there was some plumbing to expose this a bit more.
23 minutes ago [-]
AlphaSite 10 hours ago [-]
I know it sa toy, but if someone gets the bright idea to do this for real: please learn from npm and dont duplicate packages for every clone of a project. Share them between projects like every sane package manager.
matsz 6 hours ago [-]
> Share them between projects like every sane package manager.
I'd argue the other extreme is less sane. Pip installs everything system wide and you can't have different versions of the same package without venv.
Even early NPM was much much better than the pre-uv Python situation. (TBH even with uv it still feels hacky at times.)
zelphirkalt 45 minutes ago [-]
Before uv there was poetry, and before poetry there was pipenv, before pipenv there was virtualenv. I wish people would stop portraying Python tooling completely wrong like that. uv is not the first tool to solve most problems in this space. It may be the best performing though and may be the best overall currently.
diversen7 2 hours ago [-]
Virtual venv existed before uv. So you could still just generate a virtual venv and then use pip to install packages in the local venv. (2007: virtualenv was released as a third-party tool).
brabel 6 hours ago [-]
The global repository should support versions obviously.
dissent 4 hours ago [-]
If you can point a package manager at a git repo and use it like package, this is accidental convenience. Source code repositories should be factored as source code, with a build step to transform them into packages. For some languages that means compilation, for others it means transpiling, minifying, or just copying files. The resulting artifact is a different shape, designed for consumption.
If you use git for packages, then your repo becomes the package boundary. You no longer have the option of producing multiple packages from one repo, or even one package from multiple repos.
fireflash38 11 minutes ago [-]
> If you use git for packages, then your repo becomes the package boundary. You no longer have the option of producing multiple packages from one repo, or even one package from multiple repos.
What does this even mean?
I'd argue that having the source to build the thing is more important than the artifacts. Release artifacts are more of a convenience. If the thing doesn't build from the source given, what use is it?
orliesaurus 10 hours ago [-]
I just have a feeling the developer-experience wouldn't be the same - but that's just a temporary issue perhaps?
bellowsgulch 8 hours ago [-]
I find https://github.com/andrewmcwattersandco/git-fetch-file more useful. It's manifest is nearly the same as a .gitmodules file, but having specific control over what files you want to pull, or what commit or tag, or just the equivalent of latest is way more practical day-to-day.
bionade24 2 hours ago [-]
How does this compare to `git subtree`, which is part of git itself ?
If I have a 20GB submodule I'd usually just do a `git clone <url> <path> && git submodule add <path>` and it will be treated the same by git. But now I can just delete it and it's purged. And it is more portable less fragile in some ways because it's not de-referencing a gitfile. I prefer my repos to be more bottom-heavy and to not clog my modules folder.
I have a rough script that's the inverse of `git submodule absorbgitdirs` but it's a bit fragile.
It would be cool if there was some plumbing to expose this a bit more.
I'd argue the other extreme is less sane. Pip installs everything system wide and you can't have different versions of the same package without venv.
Even early NPM was much much better than the pre-uv Python situation. (TBH even with uv it still feels hacky at times.)
If you use git for packages, then your repo becomes the package boundary. You no longer have the option of producing multiple packages from one repo, or even one package from multiple repos.
What does this even mean?
I'd argue that having the source to build the thing is more important than the artifacts. Release artifacts are more of a convenience. If the thing doesn't build from the source given, what use is it?