Re: Guix as a Guile package manager

[Fabio Pesari <fabiop@gnu.org>]

On 01/09/2016 03:35 PM, Amirouche Boubekki wrote:
>
> Can you explain what a Guile specific fork of guix will bring over guix?

See the last part of this post.

>> User should be able to upload packages but each package should be
>> carefully reviewed (possibly by the community itself).
> 
> This is not how pypi works for instance.

But that doesn't mean Guix should follow suit. Implementing approval
like Savannah does is a bad idea, because packages get stuck there for
ages and there's a lot of centralized power, but putting packages in a
public queue which users can vote and allow packages to be reported for
being nonfree and let maintainers be moderators is a better idea.

> I just checked the documentation [1] and it's possible to have third 
> party
> repositories but the policy is to not fork the effort and package guile
> softwares in guix.
> 
> [1] 
> https://www.gnu.org/software/guix/manual/guix.html#index-GUIX_005fPACKAGE_005fPATH

Where's the bit about forking? The page is too long and I couldn't find it.

> My question is: what must do a guix fork that guix doesn't have already?

It's not about functionality, it's about purpose.

The "fork" is not really a fork, but rather a separate program which
uses the same core library as Guix (which I defined as guile-guix
earlier). In practical terms, it would use a different repo and have
different defaults tuned to Guile development rather than system
maintenance.

If the Guile devs decided to adopt Guix as it is right now as the
official package manager like Perl's CPAN or Ruby's Gem, they would have
to ship Guix with Guile, but that doesn't sound right in my opinion
because Guix has a much larger scope and different purpose than CPAN and
Gem and users could perceive this as adding bloat and/or a tool that is
largely unrelated to Guile development - much like bundling Emacs
because it has good Guile editing capabilities.

It would also make more sense to distribute Guix as a separate program
rather than require users to run a command like "pacman -S guile" to
install Guix, but the same does not apply to the Guile package manager
obviously because package management for Guile can be seen as part of
the Guile environment (like it is for Ruby, Perl, Python, Go, Chicken,
Racket, Emacs, etc.)

The way I see it:

* Guile ships with guile-guix (a library that implements much of Guix'
  package management capabilities, but not the Guix program) and a
  (very small) Guile package manager which depends on guile-guix

* Guix is distributed separately as a (very small) program which
  depends on guile-guix

Just to be clear, Guile does not depend on guile-guix, it just is a
library that is shipped along with Guile and on which the package
manager (also shipped with Guile) depends.

The only side effect from doing this is that Guile's size in bytes would
go up a bit, however it'd still be smaller than Python and it would gain
package management capabilities. If that is not acceptable,
I think that distributing the Guile package manager as a standalone
package (like npm or composer) would still be a good thing, but I'd make
it a separate program from Guix anyway for the reasons mentioned above.