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.
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.
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
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 (GitHub - Zatvobor/tirexs: An Elixir flavored HTTP client and DSL library for Elasticsearch · GitHub) code a little hard to understand, and felt it was over-engineered for my purpose. So I created a little library (GitHub - radar/elastic: A thin veneer over HTTPotion that talks to Elastic Search · GitHub) 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!
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.
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:
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.
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.
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.
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.
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.
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… ^.^