As part of a general sweep through the purescript-contrib organization libraries, @garyb and myself have put together a list of libraries which we would like to deprecate to keep the -contrib maintenance workload manageable.
This helps ensure we can keep contrib libraries up to date and that our continued effort to document libraries is focused on libraries actually being used.
By “deprecation” I mean that one of two things happens:
The library is adopted by a new maintainer and moved to their personal account, no longer maintained by purescript-contrib
The library is officially deprecated and moved to the purescript-deprecated organization, with the notice uploaded to Pursuit and with recommendations for alternative libraries or approaches to use instead. It can still be installed, but the repository becomes read-only and no further updates are applied.
We’re opening deprecation notices on the affected libraries so that folks can weigh in. We’ll wait at least for 2 weeks before deprecating anything.
Our main criteria for selecting libraries included:
Libraries which have seen no activity outside compiler updates in the last several years and through GitHub code searches have either no users or the only users are one-off projects which are several years old
Libraries which have become outdated and have clearly superior alternatives that should be used instead, especially those which haven’t followed compiler updates
Please feel free to weigh in about these changes as a whole in this thread, or to weigh in about a particular library on its issue tracker!
Affected Libraries
These will be edited as new maintainers are found, repositories are transferred back to their original authors, or the libraries are officially slated for deprecation.
May need discussion or to move to new maintainers
purescript-strongcheck
Originally QuickCheck wasn’t stack safe, which was the major reason to use StrongCheck. However, that’s no longer the case, and StrongCheck is significantly slower than QuickCheck. StrongCheck has some additional check types, but @garyb has never used them, neither have I, and it’s not clear they justify keeping the library around instead of favoring QuickCheck as the standard.
purescript-machines (new maintainer found: @paluh)
The library is only used in StrongCheck. It would be nice to develop it further and include Moore also, but realistically the -contrib maintainers aren’t going to do it (discussion here). There are better alternatives in the PureScript ecosystem for the streaming use case covered by machines, namely the coroutines libraries.
purescript-lens
From @joneshf, the author, back in 2018 (this has become more true since then):
“I’ve mentioned multiple times that I think we should deprecate this package in favor of the profunctor version. The profunctor version is easier to understand, more active, and seems like the de facto way to work with optics in PS. Near as I can tell, it has feature parity, so nothing is lost.”
purescript-jquery (returning to original author: @paf311)
Has no current maintainer or any activity in many years. There is some scattered usage on GitHub, so we may simply mark it unmaintained rather than deprecate it, but we are unlikely to continue maintaining the library over time. This library is linked in the original PureScript book, but without any accompanying code or exercises and it has been dropped altogether in @dwhitney’s fork of the book (the current recommended resource for learning PureScript).
purescript-foreign-lens (returning to original author: @paf311)
Not used in any active projects on GitHub. Used in a few archived projects or small projects not updated in the last 4 years, and even in those places we’re of the opinion that the Foreign data type probably shouldn’t even be manipulated with lenses (there are better ways to work with foreign data, namely parsing it and manipulating the resulting PureScript types, even if that’s just parsing to the Json type). If someone else wants to take over private maintainership of this library then it doesn’t need to be deprecated, but we don’t feel it’s the best fit for -contrib.
purescript-react-addons-css-transition-group
This library is not used anywhere on GitHub, and its functionality can easily be replaced with a foreign import (also see this issue). The contrib organization is unlikely to continue maintaining this addon, and it can move either to a private maintainer or be deprecated.
Deprecation highly likely
purescript-sammy, purescript-handlebars (returning to original author: @paf311)
These are thin FFI wrappers which appear unused and have not been maintained for several years.
purescript-base
This library is long out of date and not useful in the age of package sets. It does export a Base module which acts as a fat Prelude, but this not really being used and applications will generally define their own custom prelude if they need one.
gulp-purescript, grunt-purescript, grunt-init-purescript
In 2020 the vast majority of users have long moved to Webpack, Parcel, and the like to manage PureScript / JavaScript projects. These libraries are long out of date and even had they been maintained over the last several years we would recommend using the alternatives for any PureScript user today.
@garyb and myself have put together a list of libraries which we would like to deprecate to keep the -contrib maintenance workload manageable.
(…)
This helps ensure we can keep contrib libraries up to date and that our continued effort to document libraries is focused on libraries actually being used.
That is really great initiative.I think that this move can also save some time of the newcomers too. Thanks Guys!
I want to ask about purescript-machines. I have to admit that I’ve not used coroutines because it was too hard for me to understand its internals enough. machines on the other hand from my perspective is cleaner and simpler (it is smaller lib) with a readable formulation of the mealy machine. I was able to grasp the concept and even make some variations of it on my own
So from my perspective it has educational value as a gateway drug into the state machine programming world.
I would like to say that machines has its own practical value too (I’m using it in the production) but like I said I’m not able to estimate how much it overlaps with coroutines.
Going to the point. I would happily become a “Machines Maintainer”.
If you could suggest me a Credits note which I should put to the README it would simplify my maintainer’s life a lot…
I could also add a note about coroutines to the docs but I should know how to describe the relation between these two libraries. Would you be so kind and suggest me something?
Could this problem be solved by just writing a tutorial/guide that explains how it works and how to use it as opposed to continuing purescript-machines?
Could this problem be solved by just writing a tutorial/guide that explains how it works and how to use it as opposed to continuing purescript-machines?
Having tutorial/guide which dives a bit into the internals would be really great for sure! On the other hand I don’t think that there is anything wrong in having in our ecosystem a library which provides simpler Mealy implementation (+ extra stuff).
Being able to freerly use and adapt this simpler design is apparently an useful skill
I also don’t think that this particular lib can cause some unnecessary ecosystem fragmentation. Like I’ve written above I want to add an informative notice about coroutines to the README / docs.
@paluh With your interest in maintaining the library we certainly won’t deprecate it! Would you rather keep the library in -contrib or move it to your personal account?
I can get back to you on credits and the comparison to coroutines a little later.
On the other hand I don’t think that there is anything wrong in having in our ecosystem a library which provides simpler Mealy implementation (+ extra stuff).
Being able to freerly use and adapt this simpler design is apparently an useful skill
That makes sense. Perhaps machines could serve as a fundamental building block in one’s conceptual understanding of things, and, only if they needed something more powerful, they switch to coroutines?
coroutines isn’t really more powerful than machines. I don’t know of anyone really using coroutines anymore, mainly because I consider the library as-is to be quite anemic. Halogen uses it as an implementation detail, but it isn’t fundamental and it’s usage is very limited. You can probably do more with machines out of the box than coroutines just because it has it’s own set of Preludy functions built in.
What if we deprecated coroutines instead of machines? machines does seem to be simpler on the internals because it’s not using FreeT. I guess what’s the pros/cons to each library?
If someone wants to maintain them, then there’s no reason to deprecate either. Halogen still uses coroutines as far as I know, so it can’t be deprecated, but it’s essentially the only user I know of (maybe thermite?). Both libraries are incomplete for any general stream processing, and I wouldn’t really recommend using either of them. Note, there’s also pipes, and run-streaming, both of which have full preludes. I’m not necessarily recommending those either, but you can at least implement any stream-processing workflows with those relatively hassle free.
Try PureScript uses purescript-jquery. If any of the libraries I wrote or maintained and then contributed to contrib are going to be deprecated (jquery, coroutines, foreign-lens, sammy, handlebars), I’d rather just move them back to my personal namespace than see them deprecated.
@paf311 In that case I’ll make sure those don’t get deprecation notices and we can transfer them back to you. There’s no plan to deprecate coroutines, but we can do that for the other libraries.
Thank you for your efforts on these libraries. They’re perfectly fine, but fall outside the scope of what we’d like to continue maintaining within contrib.
Perhaps we should open “intent to deprecate” issues on the relevant repositories so that people who are watching the repos but are not on Discourse get a chance to respond to these plans too?
It is really up to you and how you feel it is better to organize such kind of contrib. I think that if it stays in -contrib I would feel a bit more responsible for it
@paf311 I’m not able to transfer repositories from the -contrib organization to you directly. Instead, I have invited you to the -contrib organization so that you can transfer these repositories back to your account based on this message:
Try PureScript uses purescript-jquery. If any of the libraries I wrote or maintained and then contributed to contrib are going to be deprecated (jquery, coroutines, foreign-lens, sammy, handlebars), I’d rather just move them back to my personal namespace than see them deprecated.
These are the libraries affected by your message – we’re still planning to maintain coroutines:
If you would like to be removed from the purescript-contrib organization after the transfer just let me know privately or here and I can make sure to take care of that for you. Thanks again for your work on these!
In that case let’s keep it in the organization, and I’ll add your name as maintainer in the README. I would love to see documentation for all contrib libraries, so if you have any insight into how we could get at least documentation comments on the functions in the modules that would be a great start. I unfortunately haven’t used the library myself so I’m not in a great place to supply that documentation.
Thanks for your interest in maintaining the library!
Yes, this needs to happen! I’ll be opening these issues for libraries which are not moving back to their original authors (jquery, sammy, handlebars, foreign-lens) or which have found maintainers in the meantime (machines)
A special case is gulp-purescript, which has a proposal to deprecate but warrants more discussion than the others as it does have some (though very little, and nothing that couldn’t be replaced via pulp / spago / webpack / parcel) usage.
