Consider supporting package aliases / remapping

Offen
  • Stimmt etwas nicht?
#354 8 Kommentare 1 Reaktion 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Bereich
tooling

Rechercherichtung

Start with the linked v1/Address.dhall definition and the package-set representation described in the issue. Compare the current Registry constructor with the proposed name remapping, then determine the required package-manager behavior for direct and transitive dependencies. Done means an agreed design and implementation scope for aliases or remapping.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Every entry in package sets produced by the registry uses the Address type, where a package set is a Map PackageName Address, ie. key/value pairs between package names and addresses:

https://github.com/purescript/registry/blob/561aa941c976d1fda6e9622a658394b5e2924d61/v1/Address.dhall#L11-L14

A registry-produced package set can only use the Registry constructor, so the package set is essentially a list like this:

{ package-name = Registry "1.0.0" }

This indicates that when package-name is listed as a dependency in a project, package managers should fetch package-name from the registry at version 1.0.0, read its dependencies, and fetch all those dependencies following the same process.

This works just fine in the usual case where you bring in packages from the registry, but there are some times where this becomes inconvenient. Two examples were brought up in the registry call this morning:

  1. You are developing an alternate backend like purerl and you need to use forked versions of common packages like prelude, because you need to re-implement the FFI.
  2. Your company is using the JS backend, but you are using a custom fork of prelude anyway, and you need for prelude in package sets to point to your forked prelude

How can users deal with these two situations? For example, if you are developing a purerl-compatible package set, where packages using the FFI are forked to their purerl- equivalents (ie. purerl-prelude replacing prelude), then what is the most straightforward way to produce this package set?

The suggestion that was raised in the registry call this morning was to introduce a name field to the Address type for the registry, ie.

 let Address = \(externalPackage : Type) -> 
         < Registry : { name : Text, version : SemVer }
         | External : externalPackage 
         >

Then, users can remap package names, ie. the prelude could be mapped to purerl-prelude while other packages are left alone:

-- prelude is remapped
{ prelude = { name = "purerl-prelude", version = "1.0.0" }
-- bifunctors is not
, bifunctors = { name = "bifunctors", version = "1.0.0" }
}

When a package manager sees prelude as a dependency in your package, it is meant to fetch purerl-prelude instead. When it sees bifunctors as a dependency, it should fetch that package as usual, and when it sees in the bifunctors manifest that it in turn relies on prelude, the package manager should recall that prelude has been remapped to purerl-prelude and fetch (or cache) that.

Vorherrschende Sprache
PureScript
Sterne
95
Forks
79
Ø Merge
16 Std. 13 Min.
Gemergte PRs (30 T.)
14

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus purescript/registry-dev

Alle Issues in purescript/registry-dev

Ähnliche Issues

Weitere Issues zu DevTools

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.