Remove legacy packages that do not solve

[MonoidMusician]

And prevent reupload.

I think our integration test isn't doing the exact thing we need (for two reasons: I think part of it is still mixed with Bower data, and it only checks for the most recent version), but it gives an idea of which packages are problematic:

``` bifunctors@0.0.3 bifunctors@0.0.3 free@2.0.0 free@3.3.0 lazy@0.1.1 lazy@0.1.1 quickcheck@0.3.1 quickcheck@0.3.1 transformers@0.3.0 transformers@0.3.0 ace@2.0.0 ace@2.0.0 aff@2.0.2 affjax@3.0.2 affjax@3.0.2 argonaut@0.9.0 argonaut@0.9.0 argonaut-traversals@2.0.1 arraybuffer@11.0.0 arraybuffer@11.0.0 coroutines@3.1.0 fork@1.0.0 formatters@0.1.0 formatters@0.1.0 matryoshka@0.2.0 matryoshka@0.2.0 parsing@0.1.5 parsing@0.1.5 profunctor-lenses@2.6.0 routing@4.0.0 routing@4.0.0 string-parsers@0.2.0 string-parsers@0.2.0 node-child-process@2.0.0 node-child-process@3.0.1 node-fs@2.0.0 node-fs@2.0.0 node-fs-aff@2.0.0 node-fs-aff@2.0.0 ```

Related:

• https://github.com/purescript/registry-dev/issues/300
• https://github.com/purescript/registry-dev/pull/465

[MonoidMusician]

Here's the full list of package versions which fail to solve:

https://gist.github.com/MonoidMusician/0f0c4ed70edf7c000a1da012bdca5134

Definitely too many to fix 😄

I'm fairly sure this list is accurate, pending more verification of the latest iteration of the solver. That said, I don't think I made substantial changes to the core logic of the solver so I'm fairly confident in it. In fact, all but 2 of these failures were found with merely the transitive dependencies check in the solver, not the full logic for picking versions.

Interestingly, all of the integration test packages failures I listed above are included in this new list, which I was not expecting since (afaik) that was running on mixed registry/bower data, although it was filtering out packages that just failed to solve on bower.

[f-f]

How could these be published under Bower? If they don't solve they should not go through their publishing process, right?

[MonoidMusician]

I don't think bower checks for solvability on publish, does it? I think it kind of just tags it on GitHub and calls it good. Also it's easy to get into a weird state with bower, where deleting the bower_components directory results in updating a lot of packages that were stuck at old versions or something.

[f-f]

I don't know if Bower did check automatically, but pulp publish requires running bower install, which tries to solve.

What I'm trying to get at here is that this amount of unsolved packages is definitely suspicious and worth some investigation. Having a lot (or any, really) of unsolvable packages in the Registry would be a problematic situation, and I personally think we should try to resolve it before we declare this stable.

[natefaubion]

It's not clear to me that any of these versions are available on pursuit, so pulp publish might have never happened.

[MonoidMusician]

I should organize them by date, as I suspect most of them are pretty old and not relevant to current development, but I don't have that information at hand yet. Obviously some are unstable versions 0.x.y, so it's a bit less surprising that they fail.

It does appear that most of the failures I looked at are not on pursuit, either due to neglect or because they predated pursuit or common publishing to pursuit.

About the only ones I could find on pursuit at first glance were the versions of prettier-printer, but their error here is that we don't have a dependency in the registry:

721. prettier-printer@1.2.0
  No versions found in the registry for pipes in range
    >=5.0.0 seen in spec@2.0.0
    <6.0.0 seen in spec@2.0.0
722. prettier-printer@1.1.0
  No versions found in the registry for pipes in range
    >=5.0.0 seen in spec@2.0.0
    <6.0.0 seen in spec@2.0.0
723. prettier-printer@1.0.1
  No versions found in the registry for pipes in range
    >=5.0.0 seen in spec@2.0.0
    <6.0.0 seen in spec@2.0.0
724. prettier-printer@1.0.0
  No versions found in the registry for pipes in range
    >=5.0.0 seen in spec@2.0.0
    <6.0.0 seen in spec@2.0.0

I don't know why we don't have pipes@5.0.0 given that we have its other versions …

A recent failure: spec-discovery@7.0.0 was an update for PS 0.15.0, not published to pursuit, that introduced a spago config but did not bump bower.json, but it was followed up with another version 8.0.0 that did update bower: https://github.com/purescript-spec/purescript-spec-discovery/releases

[thomashoneyman]

I would be curious to see if, with these removed, we can try to make ManifestIndex care about packages being solvable if we want — if you all see value in that, otherwise we can keep it:

https://github.com/purescript/registry-dev/blob/a2f872e35158274228ff0472ceb64c09634ee53b/lib/src/Registry/ManifestIndex.purs#L110-L122

Also, we could disable the LegacyImport exemption in the API pipeline, so that all packages including legacy ones are forced to solve to be included. At that point we know the manifest index remains full of solvable packages.

[thomashoneyman]

As per the registry call, we are going to:

1. Remove packages that do not solve
2. Leave ManifestIndex unchanged
3. Remove the exemption for legacy packages that says they don't have to solve. All packages must solve.
4. Revisit the registry trustees issue (cc: @f-f) to spec the process by which trustees can adjust version bounds for unmaintained packages that would work with later bounds than they currently specify and which are preventing other packages from being uploaded.

[f-f]

To expand on the comment above, here's a recap of the discussion in yesterday's call:

• removing legacy packages that do not solve is necessarily intertwined with requiring that new packages are solvable, because otherwise there would be no way to prevent other unsolvable packages from getting into the registry again
• however, instating this requirement would cause a cascading effect in the ecosystem, as everyone would need to start being conscious about their own version bounds, and their dependencies' version bounds. We'd have the same dynamics that exist in e.g. Haskell-land today, where some package authors have to hold off publishing a new version of a package, because some of their dependencies have bounds that are too strict and do not include newly published versions, so they'd have to send a patch, wait for the merge and the release of a new version - rinse and repeat for however many dependencies keep their bounds strict.
• this is not even the worst part of it: if any package in anyone's dependencies is unmaintained and can't merge even very simple bounds-bumping patches, then the whole ecosystem could be held back. Right now this is not a problem because basically everyone uses package-sets, where we do ignore version bounds.
• in order to take care of this issue of unmaintained packages, the Registry RFC proposed a system of "Registry Trustees" (the @purescript/packaging team), that would take care of publishing revised bounds for packages that are not maintained, do not require code changes, and only need their bounds bumped to keep the ecosystem moving.
• the above link is all we have for now, and this is all underspecced. To actually put this is place we'd need to clarify a few things, e.g.:
  • define the rules for when a maintainer is considered unresponsive and the Packaging Team can take over bounds updates, in order to minimise strife between maintainers and the Packaging Team
  • how this bound updates would happen. Ideally we'd add a Trustees-only API Operation here on GitHub, much like the Operations for handling package-sets
  • how these "new versions" would look like when published, and how package managers would access them. This has been discussed in #80. My proposal for this is to allow Trustees (and them only) to publish versions with a custom "build metadata", e.g. 0.1.0+newbounds01. This would allow us to keep the registry working by using these revisions, but would allow package managers to opt-out of them if need be (since they could decide to only pick versions without build metadata)