
Opensourcing the Universal Package Manager - amasad
https://repl.it/blog/upm
======
amasad
Repl.it founder here. Happy to answer questions. But also I'd like to point
out that this is not the only "universal" project we're working on. See:

\- Prybar: Universal REPL interface
[https://github.com/replit/prybar](https://github.com/replit/prybar)

\- Polygott: Universal docker image for all languages (we support)
[https://github.com/replit/polygott](https://github.com/replit/polygott)

Between these three you'd be able to add your favorite language to Repl.it
(patches welcome). We have a write up on how to do that using elisp as an
example: [https://repl.it/site/blog/elisp](https://repl.it/site/blog/elisp)

~~~
skrebbel
Wow, that's very cool.

I'm curious though, won't open sourcing all of these make it much easier for
competitors to catch up to your head start in these areas? I wonder what your
risk/reward thinking is wrt deciding what to open source.

~~~
amasad
Sure it well. We have a lot of copycats as well. But as Elon Musk likes to
say: the only moat that matters is the continuous pace of innovation and the
value of open-source outwieghs any contrived barrier to entry.

------
CGamesPlay
This is pretty cool! Lots of "configuration package managers" would benefit
from a universal interface, and many of these boil down to "directory of git
repositories at a specific commit". Some examples: many dotfiles repositories,
pathogen (vim plugins), fisherman (fish shell; exrok/fisherman).

It would be nice to have a unified way to manage these, and even better if
that unified way was through UPM, the same way I install new nodejs, python,
whatever packages.

~~~
amasad
Exactly mirrors our thinking!

Our number one priority is that the programming experience on our site is
flawless. We're playing hardmode though because we're dedicated to making the
experience across languages the same. And that's why we create abstractions
like this.

I'm hoping a project like this could at least start the conversation around
standardization of interfaces.

------
syrusakbary
This is awesome!

I’d love to work on an integration with [https://wapm.io](https://wapm.io)
(WebAssembly) and [https://crates.io/](https://crates.io/) (Rust) if you think
that could be useful!

~~~
mfer
How would integration with Rust (cargo/crates) even be possible?

Looking at how Go is so different in dependency management (Go modules
intentionally broke from the config/lock file format)... I'm not sure it could
be used there. I wonder if there are any other end cases that wouldn't work.

~~~
amasad
Crates would totally be possible. AFAICT it follows the exact workflow we're
trying to standardize.

------
intolerabletech
Ctrl-f "nix": zero results. _Come on._ What's the problem? Nix isn't my
favorite language but this is just getting to be stupidly silly. Every three
months one of these posts pop up, never going anywhere, never addressing the
already existing nearly universal package manager that literally powers tons
of workstations/servers/containers top-to-bottom.

Nixpkgs currently contains:

\- the linux kernel (and supporting bits+userspace to build an entire bootable
OS installer/disk image/PXE payload, etc)

\- tens of thousands of Linux packages (many of which also work already on
Darwin, where applicable)

\- thousands of native {Go,Python,Haskell,Node} dependencies

If half of the effort that has gone into Linuxbrew and other efforts like
this, went into nixpkgs, it would probably have even more packages and Windows
support and we could stop inventing a new package manager to rule them all
every 6 months. Insert XKCD joke here.

edit: -1, zero replies, years of being here and nothing changes. gotta love
it. Maybe do more research next time instead of NIH?

edit2: I'll donate $500 to the charity of your choice if you can show me a
"universal package manager" that contains more packages than nixpkgs (which
has existed for ages at this point). I'll wait.

~~~
joepie91_
While I understand (and share) your frustration, I don't think this is the
right attitude to express here, and if anything it's just going to
(understandably) scare people off from using it.

I personally really wouldn't want the Nix community to end up being "those
people who roll into any thread about package management yelling at people".
Thankfully, for the most part that isn't the case right now, so let's keep it
that way.

On the topic itself: yes, I think that everybody who's working on a package
manager could (and should) learn from the work that's been done on Nix.
Particularly the LISA paper[1] is a good and accessible read on why Nix works
how it does, and what problems it solves that you might run into with your
package manager project.

That having been said, that doesn't mean that there cannot be competing
implementations. The important thing is ultimately the package management
_model_ , not the _implementation_ , and it's no secret that Nix's
implementation of the model has quite a few usability and documentation
issues. Those might be easier to solve in a new implementation of the model.

In the end, everybody's working towards the same goal of better package
management. So let's default to a constructive attitude towards other projects
in the same space, rather than a tribal war.

[1] [https://nixos.org/~eelco/pubs/nspfssd-
lisa2004-final.pdf](https://nixos.org/~eelco/pubs/nspfssd-lisa2004-final.pdf)

------
MadWombat
I am a tiny bit confused. The readme says

"you don't have to figure out whether to use Pip or Pipenv or Poetry to manage
your Python packages or wade into the Cabal-versus-Stack holy war in Haskell-
land"

Python is on the list of supported languages, but Haskell is not...

~~~
amasad
Haskell support is planned. The idea is to cover as much surface area as
possible. Help would be appreciated too.

------
krupan
I'm really grateful for the explanation of Project Package Managers in this.
I've never come across that term and it makes the idea of per-language package
managers make a whole lot more sense to me, as long as they are used that way.
Without that concept, I lean much more towards using system packages. I'm
going to keep Project Package Manager in mind from now on.

------
krupan
This is awesome! I started a wrapper around system package managers because of
similar frustrations (pull requests welcome!):

[https://github.com/krupan/package_commands](https://github.com/krupan/package_commands)

I really don't know why all package managers don't use the same simple
commands.

~~~
Terretta
Mental models of the creators

------
RocketSyntax
What are the advantages over conda?

~~~
aaronchall
I would imagine the advantages are more languages than R and Python.

------
eeZah7Ux
Use OS packages instead.

~~~
pjmlp
Right should I package it as deb, RPM, tgz, deploy, p5i, pkg, msi, msix, appx,
apk, aar, ipa, ISMP or do you have any other favourite OS package format in
mind?

As fun game you can try to map those package formats to their respective OSes.

~~~
archi42
To be fair, isn't deb/apt already open source? If you don't know it, check out
the "competing standards" xkcd.

If I was a FOSS dev, I'd say "screw it; just let people pull the git and
package it however their distribution wants it".

~~~
roblabla
I mean, for 99% of the packages in most distribs, that’s how it works. Someone
makes a cool binary, someone else packages it up and submits it to their
favorite distro’s package manager.

