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?
5 Likes
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.
11 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.
5 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.
36 Likes
P.S.: well, since February 2022 my main machine is not Raspberry PI, but a more performant one.
5 Likes
Putting a limit on number of packages per account is not practical, because Hackage does not collect government ids and user can have as many account as he could. After getting second account he can approve yourself.
I am against any limitations. It hampers ecosystem development.
It is not a Python pip with crowd of developers.
Code gets obsolete quickly. Hackage is a part of UNESCO or a museum with current policies. Hackage is designed before GitHub and clouds so it had an important role of last resort storage and loss of a package had disastrous effect. Today it is not a big deal - sources can be pulled from some Git cloud.
Names of unused packages should be available for automatic override (e.g. build fails for 5 consecutive years with latest GHC release and no releases).
If package page on Hackage mentions somewhere history of overrides it would be enough.
Package release should get UUID from Hackage (upload once) - these UUIDs should be stored in some dot file next to a cabal one in user repos.
Then package name is just a symlink.
1 Like
+1 on no limitations being needed
3 Likes
Just to further hammer in the point that no restrictions are needed. Even assuming the worst case scenario and all packages from someone prolific will eventually be unmaintained, in my opinion this is still better than that person never publishing a package due to fear of being unable to maintain the packages long term.
I have 2 small niche packages on hackage and if there were more hurdles that number probably would be 0.
For instance there is a package called dynamic-loader it is the only way i could find of loading compiled haskell modules without a dependency on ghc the library even if i weren’t so incredibly lucky and it didn’t work on modern without prior work i wouldn’t even be aware that i can somehow hook into the RTS to load modules
4 Likes
One - probably off-topic - issue about names is still there: adding namespacing. If all packages go into a user-/group-dependent namespace, everyone can have an e.g. array package, but the official one would be haskell:array. I guess it would look something lile docker references.
I’m not suggesting we go for this, but it would reduce the problem with global flat namespaces using up all good names in the first few years or users ‘polluting’ the global namespace.
1 Like
I don’t say this as an argument against namespaces, but I do think the well of good names is unlikely to run dry any time soon.
Hackage is about 18 years old and, today, there are 18,155 packages on Hackage (16,857 are not deprecated). English alone has a lot of words - over an order of magnitude more - even before you start chaining words with hyphens.
4 Likes
But namespaces would give “prolific hackage users” a way to say that they actually don’t want to sit on any name, but just to upload their package and not need to rename it. Otherwise this happens by accident.
(I understand that adding namespaces is actual work though, so someone either needs to volunteer or pay for it, i.e, how much do we really need it?)
3 Likes