Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What should we do about purescript- prefixes? #388

Open
thomashoneyman opened this issue Apr 25, 2022 · 3 comments
Open

What should we do about purescript- prefixes? #388

thomashoneyman opened this issue Apr 25, 2022 · 3 comments

Comments

@thomashoneyman
Copy link
Member

Historically the PureScript community has used a purescript- prefix on package names. For example, the aff package is in the purescript-aff repository, and it is registered on Bower under the name purescript-aff. This applies to the compiler and Pursuit, too: the purs publish command considers the "package name" to be whatever came from a bower.json's name field, and Pursuit does the same thing.

However, when we stopped depending on Bower, we moved away from prefixes. aff may be in the purescript-aff repository, but its spago.dhall file and its name as far as the package sets are concerned is aff.

With the registry this goes a step further. Packages in the registry are registered without the prefix, and their name is recorded in the purs.json manifest file without the prefix. As far as the registry is concerned (and its products, such as the package sets) there is no usage of the prefix.

This leaves us in an inconsistent state where some tooling and some conventions use the prefix and some do not. For example:

  • Repositories will continue to use purescript- in their name
  • Bowerfiles (for packages that continue to use them) will use purescript- in the Bowerfile package name
  • The registry, purs.json manifest, and package sets do not use the prefix for package names
  • purs publish can accept either a bower.json file or a purs.json file for publishing packages. If it receives a purs.json file, then it will add the purescript- prefix to the name so as to mirror the Bower naming scheme.
  • Pursuit reuses the Bower naming scheme supplied by purs publish, so everything is prefixed on Pursuit.

This is super messy! The registry has to perform some awkward processing so that things work out:

  • We strip prefixes from packages when importing them from Bower, undoing the naming scheme. We don't strip the prefix if the package is published from a purs.json manifest.
  • We have to re-add the prefixes when producing a resolutions file for publishing to Pursuit via purs publish so that the links work correctly. We don't add the prefix to the package manifest because the compiler already does that by default.

This can easily result in weird cases:

  1. What happens if a user who hasn't followed all of this sees the prefixed names on Pursuit and on GitHub and decides to use a prefixed name in their purs.json manifest (since, after all, that seems to be what all the other packages are doing)? We will not strip off the prefix when registering and then a second prefix will be added when publishing to Pursuit.
  2. What if we decide to ban the use of the prefix in package names for say 1 year so that people can switch over? Then, packages like purescript-language-cst-parser won't be able to use the prefix, even though in that case it totally makes sense: it's a parser for the PureScript language.

There's no clear answer for how to keep all of this tidy, but one idea I had is to reject packages that use the purescript- prefix by default, pinging the registry trustees — the user can opt-in to this explicitly and we can continue the pipeline, but by default we tell them the prefix is no longer used.

Regardless of everything else, we're gonna have to start putting a plan together for Pursuit, so that Pursuit itself no longer uses the prefix.

@JordanMartinez
Copy link
Contributor

There's no clear answer for how to keep all of this tidy, but one idea I had is to reject packages that use the purescript- prefix by default, pinging the registry trustees — the user can opt-in to this explicitly and we can continue the pipeline, but by default we tell them the prefix is no longer used.

I think this is a sensible default since language-cst-parser is the only one I'm aware of that actually has a purescript- prefix that makes sense.

@f-f
Copy link
Member

f-f commented May 18, 2022

In today's Registry weekly call we agreed that our first priority here is to avoid users getting confused by the legacy prefix.
Action plan:

  • just strip the prefix away from all the legacy packages
  • fail the pipeline by default for new packages if the prefix is there, but get us involved in the process in such cases, so we can eventually add the package name to an allow-list. We expect the amount of items in the list to hover close to 0. The insertion point for checking the list would be here
  • refactor Pursuit so that it doesn't use the prefixes anymore. We think it might be possible to do the change by only touching the database, but we need to investigate this and come up with a plan.

@thomashoneyman
Copy link
Member Author

The first two steps of the plan are complete but the third (Pursuit) is not yet done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants