Mentioned this earlier, but I wonder if something like https://npms.io/about would be useful for Hex. I’d wanna build it for fun
LOL, this site is a joke. It’s just the Awesome Elixir repo README (not curated at all) which is parsed into a web page.
Why you don’t take the idea and build it. Everyone agree on the fact that is an issue in our industry and at least that app is trying to fix it.
I encourage you to create something or just use the platform, giving feedback, using the ranking system, I don’t know but definitely something more than just laugh about it.
this is the reason why I don’t believe on 100% freedom. This is why I prefer having seniors with a lot of experiences driving the community decisions.
I don’t believe on the freedom when I know ignorant people can screw a decision. I am ignorant enough for no be able rank correctly the packages because I don’t know that much about ErLang or Elixir.
I prefer to create a role (like seniors inside the community) that you have to gain the truth and respect for be able to be in that role.
I just want to see this issue to be fix. I bother me that we knowledge that is an issue and we don’t try to fix it.
My point wasn’t just that the site in question was doing a poor job. My point was also that Hex.pm is actually doing a very good job. If you search for a topic you get a relevant list of items, the description, and the downloads count which helps you figure out how much the community relies on the packages.
Yes, and that’s why I don’t want to use something external and actually extend Hex.pm.
Like at least have a badge that said: Recommended by the community; or something similar.
For non curated lists that particular feature can cause problems down the road. Meteor had a similar aggregate for all packages with metrics (including a fancy graph widget.)
The problem arises when you as a new user see a package has 99e99 downloads only to find out that it’s been abandoned for two years. Well, hey it used to be popular!
I guess in the end it’s a mixture of existing solutions that yields best results but requires some amount of research:
- total downloads
- recent downloads (love that hex provides those)
- README - aka what is this package good at, API etc.
- is there a Changelog?
- when was the last release?
- how long has the package been around
- github stars
- open issues
- open PRs
- recent commit activity
- blog posts
- what do my friends use…
In the end no one can take the tough decision of what library to use of your hands and responsibility.
That is always the problem, someone has to maintain lists and whatever. A particular problem I have with a “committee” is who decides what gets in and who’s on that committee. For instance in Ruby land the most interesting stuff happening imo is rom-rb, hanami and trailblazer. For all I know, dhh probably doesn’t like them very much and I also heard that they’re not that well known/highly regarded in the U.S. I also think it’d be great if they’d take their talents to other languages (like… Elixir) but that might just be me
I agree that rather than creating new stuff working together to improve existing libraries is preferable, it’s not always possible though. Sometimes project philosophies just diverge too much or a better solution to a problem requires a wholly different approach and it’s easier to implement something new than make a backwards incompatible release of library X (like lots of people said Angular2 should have had a new framework name).
Sometimes breaks are needed and a new thing needs to come up. Like shrine in ruby for instance. Also after evaluating all other benchmarking libraries I could find in Elixir I decided to make my own (a dormant PR and low test coverage among others later though). It’s hard to gain traction for new things though…
I think what hex could do better is providing more information, and let the user do their own decisions.
Well, what information are you thinking about here? That’d be good to know in order to maybe turn it into actionable items
Oh, I cannot express how important this point is. I remember times (mostly when dealing with npm packages) when I need to dig down for a changelog only to end up reading their raw commit history and diffs. It’s not a fun experience. Human-readable changelogs should be made mandatory, and failure of providing one should be considered a crime (okay, I’m exaggerating ).
Is there a good way to test for changelogs? Many projects don’t use an actual
changelog.md but do it through GitHub releases (example).
Hmm, that’s true. Some having it as
HISTORY.md or in the repo’s wiki is not helping either. I don’t think there will be a good way to cater all the cases. This is a long shot, but it would be great if hex can somehow enforce adding changelog link (probably using a
changelog key in
package field of
My philosophic, that’s why versioning exists. Isn’t Angular team (in this case) the ones that decide to upgrade to V2 of Angular. If your company/website/whatever do not need to upgrade then just dont do it.
This is something that we have to develop. A good culture. Isn’t about dictatorship but rather than collaboration and team work.
This is the problem I have with any community, specially in NPM, because sometimes package owners are not willing to listen we ended up duplicating efforts and creating more mess.
This is why I make so much emphasis about the community and work together. At the end of the day that’s actually the issue. Between ego, personal opinions over engineering facts and so on … we ended up with projects like IO (Node)
But from IO project, I hope this community realize that the best thing to do is work together as a team
I will stop guys because I can be writing the whole night trying to explain the same thing over and over: Team work, team effort, work together …
@PragTob I love your comment btw
This is an issue I have been thinking about it, changing the sorting to be based on monthly downloads instead of all time downloads may be a partial solution.
What information do you have in mind?
Right now I think it’s better to follow the (github) link back to the source repository and find the changelog there. The source repo link is not required but most packages include it in their package.
I don’t think requiring publishers to create a changelog for them to be able to publish their package will be a good experience. When you publish the first version of your package the changelog is useless since there are no changes yet. If we enforce a changelog then I just think the people that want to include a changelog will do that, the ones that don’t want to will just fake the requirement and even if you include a changelog link there is no requirement that it will be kept up to date.
Exactly this. You list 10+ items that influence which package you will use for your project. People are not going to agree on how important each item is so it’s hard to have a curated list of “the best packages”, regardless if the list is community maintained or maintained by a few blessed moderators. Deciding on which package to use is a hard problem which requires individual research for each project.
Or a good implementation. If phoenix (for example) it’s the web framework used because X reasons (really strong and good reasons) I don’t believe that people will do that much research.
Diversity is not always good, that’s why we create kernels right? look what we created on top of those kernels or even Erlang, we don’t go back and figure out how to re-write ErLang or create something similar, because the language features and implementations are well defined …
Having both would be valuable imo - that way you can see what’s been popular in the past and what is hot currently
What about adding count of forum mentions in the past month to the mix, with a link to the lot? Other than a project actually being maintained, developer mind-share is what you’re really looking for.
Most definitely Changelogs are super important… which is why I’m super frustrated if big projects don’t have it, especially on a major version release. I might be missing something but I can’t find it for poison (which many here mentioned should be the default for x-years to come), although it just had a 3.0 release.
What I usually do then is submit an issue asking if I’m just missing where the changelog is and asking if the package would kindly add it. As a package maintainer I know it can be a drag, but at the same time it’s also nice to see what you accomplished