-
Notifications
You must be signed in to change notification settings - Fork 47
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
Mark packages from purescript-deprecated as deprecated #400
Comments
Thanks for the report. Pursuit has just recently gotten a feature enabling package deprecation -- #391 -- so we should use that here. |
I'm going to unarchive the repo so that we can move this issue there. |
Actually I think we should probably track this on the pursuit repo, since there are a number of repos which should be marked as deprecated. |
This would be great. Googling “PureScript Data.Map” brings up the deprecated |
@hdgarrood I would like to take a look at this. These are the potential solutions that I have thought of so far:
Options 2, 3, and 4 would all most likely require removing/regenerating the cache entries for any affected packages. Do any of these stand out to you as a preferred solution? Something else I haven't considered? |
The main thing is that deprecated packages only end up in As for option 2, there are potential circumstances which would cause the Pursuit database to need to be regenerated: the most likely one is a non-backwards-compatible change to the JSON format. These are rare, but they do happen occasionally, most often because of changes to the way types are represented inside the compiler (because some of the same types are used for producing the pursuit JSON upload; this is something I'd like to change eventually). We might find that there isn't a good way of preserving backwards compatibility with PolyKinds, which are coming in v0.14.0, for example, and that would require regenerating the Pursuit database. I've used this somewhat hacky script in the past for this. |
I'm in complete agreement on this.
This is good to know. I can go ahead and organize the effort to deprecate the packages living in |
Thanks! You might also run into #391 (comment) so that’s worth bearing in mind I think. That might require code changes to Pursuit. |
Noted. Once some of these deprecated packages start making their way onto Pursuit I'll take a look to see what all needs to be done for them to be properly marked as deprecated. @hdgarrood As a more general question regarding the cache, what do you think about purging a package from the cache when a new version is published? This would make new package versions behave the same as when a package is first published to Pursuit in that the cache would be generated upon first access. |
On second thought, we probably don't want to purge the entire package from the cache, as this would require regenerating the docs for every version. We would probably just want to consider purging things that could have changed from the cache (which I think would just be the index entry for the package). |
I think in this case all pages across all versions of a package would need to be purged on package deprecation, since the "deprecated" badge also appears on every module docs page for a deprecated package, e.g. https://pursuit.purescript.org/packages/purescript-strongcheck-laws/2.0.0/docs/Test.StrongCheck.Laws
Great, that is good news. I have a slight worry that this might be working just because the caching mechanism is not set up properly at all right now, though... I would quite like to completely tear up the existing caching mechanism and replace it with something simpler. I think the fact that we only generate the cached files on demand, once they are requested, is the cause of most of the unnecessary complication. If we always generated or regenerated all the relevant files immediately on package upload, we could simplify the implementation of the Yesod app quite a bit - I think almost all inbound requests could even be handled entirely by nginx that way, and perhaps only the |
I think you might be right here, as I checked earlier and the deprecation badge appeared on the package page but not on the search page. I didn't really dig much into it at the time, and when I went to reproduce later the badge was there. It certainly sounds like the caching layer could be simpler, although it seems like that's not something we'll need to worry about for the moment (as much as it concerns deprecating these packages). |
These packages now have the https://pursuit.purescript.org/packages/purescript-generics/4.0.1 |
Closing because it seems to be resolved. Thankyou! 😻 |
On the Pursuit page for
purescript-generics
, it's not possible to see that it's deprecated. I would have raised this on thepurescript-generics
repo, but it seems to be read only so I can't raise issues. Sorry if this isn't the right place to raise this, but I'm unsure if it's a problem with pursuit not being able to communicate deprecations, or the package maintainer simply hasn't marked it as deprecated within pursuit.https://pursuit.purescript.org/packages/purescript-generics/4.0.0/docs/Data.Generic
Background: while creating a new project today where I was patterning off a previous project that used
Data.Generic
(iepurescript-generics
), but upgrading purescript as well, I had a lot of installation conflict errors and I didn't realise the library was deprecated. I then subsequently had duplicate Data.Monoid imports, which felt strange given I had started from what I'd thought was a blank slate with just generics and thermite, then halogen.The text was updated successfully, but these errors were encountered: