How about hex.pm ranks based on a heatmap (also can be displayed to the user) that shows activity and stars over time aggregated. Therefor a project that may not be active (since it is ‘complete’, like canada or so) but still is getting stars today will still rank high, or a project that has a huge amount of activity recently.
2 Likes
That sounds like a good idea, but it’s not something hex.pm should do. Hex.pm should not be tied to external services such as github, but other websites can call the hex and github apis to aggregate this data.
You can even publish a package without using any source control for it so I don’t think this is good fit for the official hex website.
4 Likes
Recently I went to hex.pm and I try to find this Packages | Hex
A faker package for my factories.
From that result you will find faker and ffaker which I can that pretty much resolves exactly the problem.
Coming from Ruby I know where those names come from.
But Why?
Isn’t better to actually contribute to the same package?
Isn’t better to work together instead of allocate energy and time doing the same work?
No all the time diversity is good. In my opinion, this is the time when is not good at all.
This is exactly the reason why I started this Curated HEX packages
Hoping that the core of the Elixir Core and the Lead of the Community take a little bit of voice on the issue.
Like Phoenix, where the creator and main contributor take the time for actually teach the community good practices and contribute to the community route.
I hope the Core members and Seniors teach the community.
What is your opinion about it? And please leave your arguments, because I can’t see the why this would happen 
This is exactly why I would at least put a badge on hex.pm with that the community approve or the core contributors approve … I don’t know but something that helps the community somehow mate 
Specially that I will never understand why to have such of duplicated package It resolves exactly the same problem
1 Like
Allowing duplicate projects that accomplish roughly the same task allows for an evolution of ideas within a community.
A good example of that is within the Ruby community: there was restful_authentication for authentication, and then authlogic was the chosen one, then Devise or Sorcery.
Another example is that I found Tirexs’s (https://github.com/Zatvobor/tirexs) code a little hard to understand, and felt it was over-engineered for my purpose. So I created a little library (https://github.com/radar/elastic) which did only what I required for the projects I worked on.
If there was only an allowance for one package for how to do something in a language I think it would be pretty boring. Viva evolution!
6 Likes
I am replying in this thread instead of the other.
To be honest I think it’s a bit rude to think that some packages should not exist. Who are we in the core team or you to say that some of these packages are not worthy to exist on hex.pm?
I’m also not a fan of the thought that the core team is not doing enough for the community because we do not examine and vett almost 4000 packages. Doing this is a herculean effort and not something the core team has time for. I can only speak for myself, but I would rather focus on fixing bugs and building features in Elixir and Hex itself.
If you really want this why don’t you build it yourself and start examining packages instead of telling others they should it. Or even simpler, examine the few “faker” packages and write a blog post about which one you think it’s best.
I agree that it would probably be, maybe better to have a single “faker” package than a few doing the same thing. But like @radar said this also how innovation happen, if we only allow a single package there is a risk for stagnation. You also mention Phoenix so it’s important to note that it wasn’t the first web framework so if we only allowed or promoted a single one it maybe would not exist today.
7 Likes
I believe that most of the time that we have ‘duplicate’ packages on Hex.pm, means that there was someone who wanted to implement something themselves because one of these three reasons:
- They wanted to have a nice learn-elixir project with a small scope.
- They did not agree with the approach that the already-existing package takes.
- The original package is no longer maintained for one reason or another, with its original author vanishing into the ether.
So while I wholeheartedly agree that it is better to work together on a package whenever possible, I believe that all three of above reasons are sound reasons to start your own.
Please prove me wrong, but as it stands this feels like it might actually be a non-issue.
2 Likes
Agree with what has been said already - we should avoid doing anything that might stifle innovation. Hex.pm already allows you to sort by popularit which is an excellent way to gauge what’s hot. The only thing I’d suggest perhaps, is to have some way to see what’s popular over time, e.g.:
Of all time
Over the last year
Over 6 months
Over 3 months
Last 30 days
This could help make it easier to spot emerging libraries.
5 Likes
We store all the data already to show this information and we have open issues on hexpm to add interfaces for it so all users can consume it.
4 Likes
Could go the npm way where a package is either "<packagename>" for a ‘global’ named one, or a specific one that is "<username>/<packagename>", that allows people to fork all they want and still be accessible.
1 Like
This argument is not really valid in Elixir though - in Node, you can freely have multiple versions of a package at runtime. In Elixir you can’t. This means that if you use foo/bar you wouldn’t be able to use baz/bar - even if both did completely different things and just happened to have the same name.
1 Like
True, though that would have been an interesting design decision, put some ‘reponame’ or so as a top level module, would have helped to prevent conflicts, but eh… ^.^
1 Like
Awesome 
1 Like
Hex.pm is adding support for multiple repositories but they will not be public except for the “global” one. But I think the issue is here is exactly the opposite, the people that want a curated package manager doesn’t want forks or alternatives to packages.
Module names are not enough to namespace against conflicts. You have to also change application names, process names, ets table names and a lot of other things. The VM wasn’t built to support multiple variants of the same application loaded at the same time.
2 Likes
This is the takeaway here. Asking for some sort of committee that will rank packages is like requesting someone else to do your job. How will this committee even be able to judge all packages that go into Hex about Phoenix, GraphQL, Databases, Elastic Search, Nerves, C extensions, etc? Each of those require specific domain knowledge.
Instead we need to discuss how to assess the health and quality of a project. README, documentation, usage, number of committers depending on the project size and if the team is responsive on new issues. Then there is a whole series of aspects related to your current domain: are the APIs well designed? Is the code tested? Does it use meta-programming only when absolutely necessary?
FWIW, I strongly dislike any measure that includes commit activity. What if the package is just… done?
9 Likes
Probably that’s what I am trying to said from my frustration of watch how we follow the Ruby and/or NodeJS community path. Where you have literally one function package or duplicated work instead of work together.
I just want people to cooperate together instead of work separately. I just want a community where is not about diversity but instead something that works and it’s robust.
Every time you create a new package is like starting from 0. Diversity is good when there is a really good reason for it. In this case, faker vs ffaker is just somebody that wants to see the same set of gems in Elixir (No reason at at, and sorry call me rude but it’s true).
Why Engineers want to reinvent the wheel every time, why is so hard to cooperate as a team (even when we are not working in the same company).
@josevalim probably the only thing I am asking from the Core is to train the Elixir community about the topic … because nobody will listen to a nobody
And I has been doing my work, I do not come or ask anyone to do it for me, I has been updating this https://elixir.libhunt.com/ at least contributing to the categories sections because I didn’t use that much of packages (instead of writing a blog because writing is not my skill as you already know)
But you are right!
2 Likes
Isn’t better to try to contribute to that package? (2 people thinking together instead of 1?!?!?) See wha the creator have to say about. Probably he will create a better documentation or change the core of the package?
From your example, just from the readme you need to catch up with that package, probably doc (I dont know) and many other things just because you started from 0
1 Like
Yes I would try to contribute but as I stated before, I felt the code was overengineered (quite the liberal use of macros) and the documentation sparse. I felt it would take me much longer to understand the code than it would to write a simple® implementation myself. I was right.
1 Like
What he/she (I dont know) said about it? Did you explain him/her your concerns?
1 Like
I didn’t explain my concerns because I didn’t think I could phrase them in a kind way. “Hey mate, your liberal use of macros scares/confuses me. Care to tidy it up or document it?”. I also noticed there were recent issues in the issue tracker which weren’t attended to and so if I filed one too then it would just be another issue on the pile of ignored issues.
What I wanted was some simple-to-understand Elixir code to communicate with Elastic Search. I didn’t find it after a cursory Google search, so I built my own. It was only later I discovered a similar project: https://github.com/werbitzky/elastix
Since I’ve got my own version running in production now and don’t have any real reason to switch to elastix, I’m going to continue using/maintaining my own.
Maybe one day down the line the maintainer of elastix and I will agree that it makes sense that only one implementation like this exists and merge the ideas from our two projects into one, but for now it’s fine that they exist as two separate entities.
3 Likes
I agree with your reply. Communication is important and we should seek for collaboration. Elixir tries to lead by example here up to some extent when it comes to Erlang integration. Pushing developers to not simply wrap Erlang abstractions and contributing improvements, reporting bugs and more upstream whenever possible.
Btw, I didn’t want to imply you were not doing work. Although reading back I can clearly see how it can be read exactly as that. Sorry.
3 Likes
