I came across this PKGX tool the other day, if anyone here is using it, could you share your experience?
I’m wondering how useful it would be to have Elixir bindings for PKGX… I know that some elixir libraries like esbuild and tailwind depend on those being packaged as a standalone binary, and it feels that PKGX could make running those tools a lot easier.
While it is certainly advertised as cross platform and “runs anywhere”, it is currently mac and linux only.
It says that Windows native is coming soon, so I guess it’s on their roadmap!?
pkgx is an interesting idea, but there are IMO issues.
Aside from one of them, they are somewhat minor and technical (no support for fish shell; packages managed with pkgx must be relocatable, which may mean substantial maintenance or potential divergence from upstream).
The one that’s not minor is that it’s part of Max Howell’s tea token web3 project. (Related to this, they have raised at least US$17M for the web3-ification of open source development. They will have to make this money back somehow.)
It bills itself as:
It’s
npxfor everything else
I don’t have a very high regard of npx so that’s a turn-off for me right there.
This seems to be homebrew (binary distribution) + a command to execute stuff within the enviroment over linking executables into system directories. I would hardly call interesting tbh. Also I don’t want to see their github actions bill: Workflow runs · pkgxdev/pantry · GitHub
I’ve spotted pkgx a while ago but found it very messy in terms of implementation and wasn’t sure it would treat my machine well (and whether it will leave a lot of traces and leftovers) – granted that was not a 100% informed opinion, it was based on reviewing random pieces of code over the course of 15 minutes max.
One thing is clear though, we need a much better way of finding / installing / running AND updating programs. Especially the updating part is sorely lacking in many ways, f.ex. if you want to track a latest Golang binary executable then you have to install tools like gup in order to be able to mass-update such binaries.
Same goes for the cargo install-update Rust tool. There are others as well.
And don’t get me started on the various zsh plugin managers, we have no less than 8 separate “plugin managers based on GIT” which are more or less just scripts that do git clone and then subsequently git reset --hard && git pull on a list of directories. Tragic.
But all this underlines how sorely lacking this area is. Of course this also shows how much do we need immutable OS-es where you can temporarily install tools and “lose” them on reboot (or manually; or choose to retain them and put them in the immutable image), and how badly do we need sandboxing as well.
…And none of that even touches on “transactions” on the file system that were needed like 40 years ago and are still not implemented in the mainstream kernels. The file system should be a database.
“Modern” OS-es are pretty primitive still.
/rant
NixOS ticks a lot of boxes. I find nix and NixOS, for me, is a much better solution than all the previous language version managers I’ve used before. nix develop shells are awesome once you get the hang of them.
Nix/NixOS does so many things right but is perhaps too hard/different and too steep learning curve to gain wider adoption. In some ways it is similar to erlang which has some great tools and technologies and were way ahead of competition in many places but people picked js on the server. Once you learn the beam you see the light and other technologies become a bit tainted.
When I look at code implemented in other other languages I think: “That would be trivial on the BEAM”. I feel the same thing about Nix and NixOS when I read about all the installation problems and incompatible software and the like. “It is already solved with nix, why go through all that pain when you can live in nix purgatory instead?”
The problem is most people rather do the easy way over the “right” way and hence the mess we are in. 
I refuse to learn a dysfunctional Haskell dialect – and that’s not even the most prominent problem… that’s actually the most minor one. They’ll have to try again with something else because their error reporting is abysmal and they require a huge investment of time and energy to get to an operating level.
I am eyeing stuff like immutable Manjaro or Fedora lately.
Not sure if this is addressed to myself or other group but in my case I’ll say that from my 22+ years of experience as a programmer I am 100% sure stuff like Nix can be much easier for the user and yet it is not. I put a hard requirement on the ergonomics of the tools I want to use. Transactional mechanics on software packages or the FS itself are not a difficult thing to express yet Nix made a mess out of it. Shame.
Yes, and one thing Nix creators consistently fail to grasp (evident on their forums, though don’t ask for links, I don’t keep them) is that most of their audience are more senior IT specialists who might be pretty burned out on learning one more super specific DSL.
Allow me to disagree. It might be solved but their ergonomics are abysmal. As said above, I am waiting for something better. Though I also am about 80% along the way of rolling my own thing that simply tracks every filesystem change since reboot and computes a diff between reboots or manual snapshots. So I might end up just open-sourcing that and using it.
…Or at one point we might have ZFS or BCacheFS boot disks that both allow innate snapshotting and just end up making a thin layer on top of it. That would most likely be the ideal solution, if the kernel / grub teams ever get to allowing those FS-es as boot disks without too much ceremony.
A tad bit more aggressive than I anticipated I see nix already scarred you for life (also please, not that I am writing this tongue in cheek, not here to inflame anything (except IT industry overall)
I agree with you (although perhaps not as emphatically). Going down the nix rabbit hole is a blessing and a curse.
Yes, nix the language is awful. I just can’t wrap my head around it.
Indeed.
Hence, the nix purgatory reference.
Even though with all those flaws, it just works better, (again for me) than any other similar technology before, and it means my views on other technology is tainted. I am sure you have the same experience with other technologies in your life.
And as mentioned, I think erlang/elixir might be in the same territory. If we only could get everyone else to see how magical erlang/elixir is! But. “I refuse to learn a dysfunctional prolog/ruby dialect with abysmal error reporting (for erlang)” is generally what I hear.
I’m addressing the IT industry overall which always just puts another layer on top instead of trying to understand the actual problem and make something solid. Like the beam.
Peace
Yes, and I think we are having a tooling renaissance with a big focus on DX after the industry neglected it for so much time. And companies know that people simply don’t have time to waste.
This is why people will choose the “easy” way over the “right” way because time and energy are limited resources (especially if the allegedly “right” doesn’t come with good DX). But also because technology is a Wicked Problem, so this purist sense of the “perfect” tool doesn’t exist in practice.
At this point in my life, I’m taking whatever makes my life easier and I’m glad other people are tackling those problems because I surely don’t have time to invest in fixing this BS myself 
haha.
Sincerest apologies, please rest assured it wasn’t meant that way, I’m getting older and often don’t want to put the soft gloves.
My general stance is that our area never learns. By the time most of us are mature enough to contribute… we usually no longer want to, and then the “innovations” are left for the youngsters who make a whole huge bunch of new and exciting errors. Quite tragic.
Eh. I’m sure we’re forgiven if we do not take seriously people who judge by syntax.
At this point in my life and career I found out I can easily learn and work with most of the programming language syntaxes I ever stumbled upon – and that people’s misgivings about them are usually shallow. Syntax can get in the way of thinking about a problem and that’s a legitimate complaint but again, it’s the one that’s very rarely raised.
My only remark towards Erlang / Elixir is that we could use some more static strong typing but at the end of the day I’ll just use (or roll my own) runtime validation library and that’ll be me nailing my developer experience.
2 words: “technical debt”. I will not adopt tools that:
I don’t really get the “I don’t understand how it works myself” part, but I guess everyone can choose what they can do with their free time!? So, If your passion is understanding your whole toolchain down to the last zeros and ones, go for it - I guess tools have different audiences… This is not my reality though; these days I’m more concerned about cumulative “energy debt” and living a simpler life
I believe he meant that he should at least be able to find out the basis of how the tool functions, or he should excuse me if I misinterpreted him.
Like f.ex. how I inspected some of the zsh “plugin managers” and found out they were just thin wrappers around several git commands.
I meant they are or’ed together. Let me rephrase:
I can only adopt tools that are time tested, or does not depends on hype, or simple to understand. I don’t think PKGX check any of the boxes.
@dimitarvp I did get what @derek-zhou said haha. What I meant is that don’t necessarily share his stance on this… Although I am a curious person, I don’t feel particularly compelled to focus too much on this side of things, in other words, I like looking under the hood, but I’m satisfied with not knowing how every single piece of it works as long as it keeps working - it’s a fractal thing 
.
© Copyright Elixir Forum | Terms | Privacy & Cookies
