Again, doesn’t have to be Hex because Hex is used fro package management but the idea is the same one. I would love to see in hex website because people truth more.
@ericmj I don’t want to accept that “Hex” will finish in the same. This is why I am calling this problem now when we are not that big. Whatever takes I am wiling to help but please don’t let that happen.
The problem is that there’s no solution.
Hex’s only job is to server and store packages. No one in the Hex team wants to review packages, especially as Elixir gains traction and we get hundreds+ a week. They also don’t want a high barrier of entry for people to publish stuff either. Remember, Hex is an open source project done for fun, not anyone’s day job (correct me if I’m wrong).
The community is made up of tons of people. People are impossible to get together to agree on many things, especially tools and software. It happens very rarely and only for very big things like Phoenix or Express in Node (even then, many want Koa or Hapi).
Maintainers come and go and projects die after a few years. It’s an extra burden to keep track of which projects go unmaintained. Some projects don’t need maintenance at all after 1.0.0 because they’re simple.
Also, it’s not that bad. I get stuff done in Node all the time and rarely have a problem finding good libraries. I use npms which I linked above—their algorithm takes into account stuff you’ve mentioned and returns great results. Someone could build the same for Hex. After a few projects you just know which packages and people are good.
Phoenix, HTTPoison, Poison, Plug, Poolboy, Ecto (just naming a few) are all set in stone for years to come and the community has already decided on them, but I can go and publish 20 mediocre JSON parsers on Hex right now if I want. But you’ll never find them or use them with a good search system because you’ll get Poison instead. That’s my only solution: Have a good search algorithm and keep up with the community. Or have your own site that lists curated packages based on some algorithm you come up with.
You can’t stop people from publishing trash unless you hire someone to review packages 24/7, and then you’ll be known as the language that’s not friendly to beginners/people experimenting with packages and new ways to do stuff. I’ve even seen people accidentally publishing their Phoenix web app on Hex! Some programmers hate using dependencies, some like reinventing the wheel. People will always be silly 
Anyway, that’s my rantish answer. Let me just say I do agree with you and I’d love to have a perfect package repository with only the best stuff on it, but it’s just not going to happen.
As long as hex lets me install packages or view their documentation in a timely manner, that’s all I care about. And honestly I be pretty against any kind of moderation/curation on hex itself, as it could just lead to whole other set of problems.
Now having a separate service that curates the packages is most welcome, currently I use awesome-elixir quite often. Although solving the problem of project curation certainly isn’t easy. There’s a few different problems that come to mind.
How do you determine what is the better package? What might be the best package for one user’s use case, might not be the best for another. Look at two popular GraphQL implementations graphql-elixir and absinthe, both are great choices (and from what I’ve previously read, there’s no intention of them to be merged, they’ll both continue to be developed separately), but they take very different approaches to their API. Certain users will prefer the workflow of one of them over the other, while other users will think the opposite.
Curated lists (unless actively maintained and use filtering criteria that considers this) often don’t allow for new ideas to flourish. While you could say, those ideas should be contributed to an already established package. That’s always easier said than done, the already established project might not be at the liberty to make/adopt those changes. Sometimes it really is easier to just establish it as a new project. Now imagine someone develops an alternative to Ecto that’s better than Ecto in every possible way (I know, I know, how could that be possible 
). Given that Ecto is already established as the goto library in that space, it’s most likely that new project will never get exposure on a curated list (unless this has been carefully considered for).
Effective categorisation is a lot more tricky than it sounds. As someone gave the example of searching for “cache”. What would be the best cache package? What even is a cache? A cache related package could be applied to many different areas, solving many different problems. If the categorisation/search isn’t considerate of this, it could lead to suggested packages that don’t even solve what the person is looking for.
Now I don’t know the answer to… Well, any of those 
But they are definitely issues I think need to be considered. And they are at least some of the reasons why I wouldn’t want hex to try tackle it, at least a separate service can afford to make those mistakes while discovering what’s the best way to go about solving this problem.
I agree with most of the people here that Hex is not the right place for this idea. But I think the difference between Hex and other package managers is that it is already backed by the Elixir community, largely and well-represented on this forum, previously on the mailing list, and also now on Slack.
Building on this awesome community, I have found out that we have sticky “wiki” posts for editors and IDEs: Spacemacs, Emacs, Atom, and others. If you are researching any particular packages with a specific use case, could you not create a specific post for that use case and explain the packages you’ve found? I know I was recently involved in a discussion on “happy pipes”/railway-oriented programming libraries. Each of the different libraries had strengths, weaknesses, flavors that could conceivably be grown into/turned into a wiki?
If you create said post, and it is well researched, then the sticky post could show the various packages that exist for the use case, profiling any package’s strengths. Then over time, it grows and evolves, depending on the need for the use case. You could include any information you find relevant there, and it would be driven by moderation from the community, just as this forum is in general.
But I’m not a mod and I don’t know if this is really feasible. 
We definitely encourage Wikis here on the forum - anyone at Trust Level 1 or higher can edit them and the wiki owner always gets notified of any changes. Have a look here for more info:
@ibgib: Yes, it frequently happens, both on the Slack chat group and on this forum, that people have questions like ‘I am facing problem X, what is the best package to help me solve it?’
The nice thing about that, is that multiple people can give a very specialised opinion, based on the state of the packages at that point in time, and based on the given problem’s exact circumstances. I think this is really valuable, and one of the things I love the most about this community :).
There is a solution to the problem. I glad that somebody made it
So, here’s my issue with this kind of thing. I did a bit of searching for libraries related to 2 areas I know a lot about: AWS and GraphQL.
Search term: results
AWS: ExAws at 188k+ downloads comes in first, followed by AWSAuth and aws at 3k downloads.
Graphql: Absinthe comes in first at 24.6k downloads, the graphql package comes in 3rd at 14k downloads.
Both of these give the correct answer. ExAws is wildly more feature complete and tested than the aws library. The holds true for Absinthe and GraphQL, and the latter project hasn’t had a commit in 3 months.
Search term: results
AWS: AWSAuth comes in first for… no particular reason as far as I can tell? All the numbers on the page are lower than they are for other libraries. Next is aws, finally followed by ex_aws
Graphql: graphql package is up top, followed by their parser, followed by Absinthe.
How is this supposed to be better? Someone using this site to try to use AWS or start with GraphQL would be directed towards two projects neither if which constitutes the best the Elixir community has to offer in that area.
Searching “web” ranks sugar higher than pheonix. Grouping things by category is of no value if the results in a category send people in the wrong direction.
