One Function Packages

I was searching for some packages for email and the package is_email came out so I checked the code and I just saw this

Coming from the frustration of npmjs and people Sindre Sorhus pushing for single file modules, I really do not want to see that happen on Hex. Specially for something like that package, where it is easier to just copy paste than maintaining any package dependency.

I found myself in this position where I wanted something on Ecto or Elixir and @josevalim convince me that it is better to copy paste sometimes and I am glad that he did.

I am wondering what is your opinion about it.

My personal opinion, I do not support One Function package and what I normally do is to wait until at least I need to create a util package that holds more than just a function and even at that moment, I would just use Github dependency directly than publish it to Hex, at least I help Juniors or even other people to dealing with those packages.

1 Like

Yikes - yeah I also err on the side of minimizing dependencies. I copy and pasted a validator package for Ecto changesets (and modified it a bit) instead of installing the package wholesale.

The node/npm situation is ridiculous, I agree.

@alchemist_ubi: Not sure how it exactly was in npm, but generally if you release something under Open Source license and people find this useful then they will probably fork it, so when you delete your library then they could simple re-upload a fork of it under same or another name. People really often makes fork for adding their pull requests (PR) to main code repository.

If you really need to be sure that specified library which is used by you will be always online then you can simply fork it and use git url instead of using such package from hex.

https://hexdocs.pm/mix/Mix.Tasks.Deps.html

Remember:

The Internet always remembers.

:077:

I feel like such packages can have value, if they’re actually better executed than the quick copy&paste solution. E.g. if one would write a function which does email validation based on the rfc I’d say it’s ok. In this case it’s just wrapping a – not even correct – regex, which I find more troublesome than it being just a single function(ality). On the other hand the package has 7 commits and version 0.0.2 so one should use it with care anyways.

It is not about what I could, I am fully aware of using direct links to github but it is more about rising the awareness of such of practices.

This is pretty much https://www.npmjs.com/~sindresorhus , as today 1092 packages which many of them are one function package, sometimes just a simple wrapper with some Promise because it want to make it Async.

You are right, no everything have to be complex with a lot of functionality but I would argue that is a really low % of the cases.

@Eiji and I forget to say something.

This issue come from the lack of awareness and constant bad habbits.

If a lot of people would think the implications of the actions before doing it, they wouldn’t push to Hex just because it is as simple as mix hex.publish.

I wound myself delaying by months a lot of the projects I would love to share with the community but I do not do it because I do not want to have the same habbit of NPM/Javascript community.

I expended a lot of hours thinking on the documentation, cleaning up the package because I do care about Hex as a platform so thread like this Curated HEX packages wouldn’t exists.

Sometimes it is more about others than yourself.

Like I said, I would prefer to use myself the github dependency for my own projects than push it to Hex, I help the community, I help other engineers that do not have to deal with the nightmare of finding other people work.

The reason that this exists Curated HEX packages is because I wanted to rise the attention once again to an existing issue, I wasn’t expecting to get that much from Hex doing something but see the Seniors and Core contributors and Core Community Managers to do something about it. To speak about the issue.

Many of us do not have a decade of programming and contributing to the Open Source community so unless somebody give us a perspective in how to think we will see such of practices as something that shouldn’t be a problem.

Because it is easier to do it shouldn’t mean you should do it all the time, having the discipline of respecting other people over yourself is something that we should develop as a community.

I love that Jose is open enough for discuss about topics but strong enough for take good decisions around Elixir and what goes in (with the support to the whole team for sure, I just deal with him so far on the Core).

I love that Chris McCord take the decisions in how he wants Phoenix ecosystem to look like, rising the awareness of thinking your application beyond than just scaffolds.

But so I am hoping to see somebody that have a huge impact on the Elixir ecosystem to talk about this issue, that in my opinion is what killed npm and made it the worst package management ever so people had to invent awesome-list-of-[INSERT PLATFORM HERE]

I think I’ve previously argued on this forum that “people can just not download the packages if they don’t like them”, but when the ratio of boilerplate + docs to code is 17:1 (is_email should’ve used def(...), do:, meaning it’s literally just a one-liner, versus 17 lines of almost useless documentation) that’s just overboard.

I guess most people share this opinion: Push smaller staff to GitHub, don’t flood hex with is_*. I think the number of people sufficiently annoyed at having to write a regex to match a couple of words that they’d look for a library for it can be counted on one hand, so it’s a fair bet that that’s largely useless to the community and probably shouldn’t take up space on hex.

I think Andrea Leopardi made some good points about the motivations of making a library in this talk:

1 Like

This is why I wish hex did not use package names like blah but rather something like user@blah so anyone can make a named package but it is under a given username, so phoenix would be, say, phoenix@phoenix and phoenix@phoenix_ecto and so forth. Right now anyone can grab a name and no one can ever use it ever again even if the library died like 6 years ago (if 6 years in the future from now).

5 Likes