Plumbing for newgit as an ecosystem-agnostic package manager

Abierto
  • ¿Algo no está bien?
#202 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
git, rust
Área
build-system, devtools, security

Línea de trabajo

Start with issues #201 and #153, then read newgit-architecture.md for the existing tracker, resource, install-store, and network namespace designs. The issue identifies decisions those designs must support: refs, excluded paths, content-keyed outputs, and resource permissions. Done means those foundations preserve room for ecosystem package registries and tools, but the issue leaves the implementation scope open.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement

The idea

If trackers can mount trackers (#201) and resources run what bound content needs, newgit already has the shape of a package manager. It stays ecosystem-agnostic: we build the plumbing, and the community builds the package sets, registries, and solvers. That's how Git (plumbing and porcelain) and Nix (nixpkgs is a community repo) got there.

This is not on the roadmap. A community only shows up once the core product (agent workflows) has users. The point of this issue is to keep the door open: a few choices in #201 are cheap now and expensive to retrofit.

Two kinds of package

  • Source packages are trackers. Import any Git repo as a tracker and mount it. It's editable, keeps its history, and its audience applies. Fixing a bug in a dependency is a commit that splits back into that tracker. No publish, bump and reinstall cycle, and no stale vendored copy. You pin by forking (see #201's follow vs pin).
  • Artifact packages are resources. For opaque artifacts (npm tarballs, binaries, toolchains), a resource runs whatever ecosystem tool already exists: pnpm install, cargo build, nix develop, mise install. The community writes the resource definitions, the way people write nixpkgs expressions.

The plumbing

  1. Mounts and tracker-relative paths. Already in #201.
  2. Resources fill excluded paths. A tracker's claims exclude node_modules/ or target/ (paths = [".", "!node_modules/"], see #201), and a resource fills them. Code trackers own source, exclusions mark what's generated, and resources produce what goes there.
  3. Content-keyed resource outputs. Cache a resource's output by a hash of its definition plus the commits of the trackers it reads, and share it across instances and machines. That's a build cache. The seed is #153, which keyed the install store on the trackers an instance binds. Generalizing that key is the step.
  4. Mounting at a ref, not only main. Tags or releases on trackers, so a mount can say ui-kit@v2. Version solving (ranges, choosing one version for a diamond) is left to the community, provided the plumbing gives them refs and settles #201's diamond question.
  5. A registry is just a tracker. A public tracker listing other trackers, built on #201's per-remote trackers. It needs no special server, and anyone can run a competing one.
  6. newgit tracker import <git url>. Turns any Git repo into a tracker, keeps upstream provenance, and keeps following upstream through fork-sync.
  7. Sandboxed resources (non-negotiable). Once strangers write resource definitions, every spawn runs community code, which is npm's postinstall problem at the scale of a whole system. Resources declare permissions (network, paths, secrets), enforced by the per-branch network namespaces in newgit-architecture.md. Signing, plus provenance on imported trackers, covers the rest of the supply-chain side.

Decisions to make in #201 now

  • Mounts accept a ref, not only main.
  • Resources fill paths excluded from a tracker's claims.
  • Resource outputs are content-keyed (generalize #153's install-store key).
  • Resources declare permissions.

Further out

  • One-clone machine setup (home-manager, not NixOS): newgit clone jack on a new laptop gives you dotfiles, environment, secrets, agent notes, and your projects bound, with resources handing tool installs to mise, brew, or Nix. This follows naturally from the per-user tracker and could be a feature on its own.
  • newgitOS: the model fits (the per-user tracker is machine config, resources are services, per-branch namespaces give isolation), but NixOS's hard part is nixpkgs and twenty years of reproducible builds, not the model. Not worth pursuing unless the ecosystem appears on its own.
  • Complementary with Nix, not competing: newgit composes editable, privacy-scoped source with its history, and Nix builds hermetically. A resource that runs nix develop gets reproducible toolchains without newgit reinventing them.
Lenguaje dominante
Rust
Estrellas
0
Forks
0
Merge medio
7 h 27 min
PR fusionados (30 d)
140

Preparar el entorno

Aún no hemos revisado los archivos de configuración de este proyecto. Empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Spheroman/newgit

Todos los issues de Spheroman/newgit

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.