I’m not sure you even described an issue. Why are you upset about the 12th most prolific Hackage user? Do you think they contributed too much to the community? Do you not like their contributions? Are you opposed to breaking things into libraries so they can be independently versioned?
1 Like
Thread was opened for a Hackage question, I am sure OP is now in contact with admins and they will handle the matter appropriately.
If you want to discuss Hackage policies or package naming conventions, please open a new thread.
1 Like
The packages are too granular for my tastes, but I do not think they are sufficient in quantity to be of concern, nor do they violate any particular policies. In short, this is a bit odd, but I think is fine and requires no action.
9 Likes
As long as it doesn’t look like the user is squatting on “good” names, IMO it’s easier to leave hackage as a free-for-all: it’s relatively difficult to add criteria such as package maturity, how many is too many and what not.
3 Likes
Hello, everyone!
Actually, I am that person of discussion here.
Thank you for your interest and support of those, who support my work on Hackage!
I would like to address the point of doubts in some words.
I have been using Haskell since GHC 8.4.1 was released. Besides, soon in 2020 I switched to Raspberry PI 3B as a main development and testing board computer. It has just 1Gb of RAM and is not too performant. I have noticed then that compilation of massive many-modules packages with modules with approximately of several hundreds lines of code is a rather heavy workflow for such machines as Raspberry PI 3B. I tried to find the solution to the problem so that make available and fully usable my packages also on these machines.
And with some experimentation I have come to the following ideas.
-
You can split large modules into smaller ones so that they can be compiled with GHC-8.* in parallel much easier and with less resources.
-
Also you can split the large package into a smaller ones for better granularity control and to follow the logical structure of code where every package covers some area of functionality of the general project.
When I followed these rules, I could easily use my packages on Raspberry PI 3B and I think it is possible even on less performant and resourceful machines, at least with zRAM technology.
Further I noticed then that packages that are large can cause much heavier executables that are linked to them. Therefore, I decided to remove the vector and possibly other large packages from the dependencies of my packages. Because of that fact that I have already published several of them with useful and usable functionality e. g. dobutokO2, dobutokO3 and similar ones, I decided to switched to Array instead of Vector as a datatype for storing linear data with quick access. Therefore, I published the parallel versions of the close or same functionality with and without those heavy packages and I thought it can be seen also as a educative approach to compare different implementations.
To be honest, I have met some bugs on my implementation that showed that although semantically arrays’ functionality is in many cases analogous to vector’s one, the last one have some advantages in usage for the not too savvy developer.
To that time I have published several different versions of functionality related to phonetic languages that one which now is named PhLADiPreLiO. It is a research project inspired by dobutokO2 and dobutokO3, but it is completely independent. I gradually improved my packages in different approaches, sometimes completely rewriting them from scratch and therefore publishing by the other package names to avoid not noticeable switching in versions between.
Since 24th of February 2022 I live in country with active state of war – I am a Ukrainian, live in Ukraine.
Hackage has that advantage of immutable package publishing – once you have published a package, you cannot revert it back, you cannot delete it, you just can publish a new version or deprecate a package completely.
This is of great advantage, because you can provide functionality that can be restored in future by just changing the versions of several dependencies into the contemporary ones and everybody can use the package published decades ago.
But there is an issue related to this in PVP — if you specify some range of versions for your own packages, there is a possibility that someone can gain access to your account – in my case, under attack of Russians, it is somewhat possible scenario, and they can publish several packages together with the versions in that range and completely rewrite the functionality since that time, because by default the new installations without specifying versions will use the newest that is the exploited one…
Therefore, to avoid such possibility I switched to new model of PVP — I specify my own dependencies exact version using == operator and no >= or <= or > or < ones.
This allows to preserve the functionality of the once published package for the newer installations even in case if someone can gain access to my account.
Besides, such versioning allows to publish newer versions of some functionality as soon as it emerged without no doubts on the possible breaking by other dependencies – because of versioning they are still depended on the old versions and will continue to work the same until you publish the update to them.
These conscious decisions led to many packages on Hackage that can be potentially united into several topical repositories, but I think it is not the better choice.
I should also say that since the GHC 9* versions the compilation is much quicker because of improvements in the compiler and many of these ideas can have no meaning since these version. Still, I follow the policies described here further.
18 Likes
P.S.: well, since February 2022 my main machine is not Raspberry PI, but a more performant one.
3 Likes