Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
    Bren Eser

    Hey folks,

    I wanted to share some feedback for pearl. I really love the idea. @fsquillace I think I need to thank you most for creating this project?

    I initially intended to use Pearl as a dotfile manager but I find it not very helpful as it does not help with constant syncing/pushing/pulling and I back up configuration related to many programs including xfce, graphical apps and all, and they tend to get updated very often. There are lots of other tools which mostly focus on linking files, but as soon you want to add a whole folder to your repo they mostly cause headache and require extra effort. Recently found VCSH which uses fake git repos, started using VCSH for configuration, and in fact planning to create a kind of wrapper around VCSH ( maybe replace VCSH in the future to achieve same functionality it offers built-in) to manage my dotfiles and app configuration.

    But Pearl is still great for me acting as a package manager; purely shell and git based, with no ties to OS which I really like. I can use it on any Nix system; headless or graphical. There are plenty of great shell based projects on Github which are not available in all Nix package managers, or get out of date pretty quick. Off the top of my head I can think of VCSH, gibo, base16, N (Node Package Manager), etc.

    I created pearl-packs bundling some of these tools to be able to install them and not worry about modifying bashrc or zshrc as most of these tools require this manual work to function and achieve shell completions, which I wanted to automate using Pearl.

    So, what do you guys think of improving Pearl as a package manager as well ?

    I think it can be improved making it available to be installed with bpkg and make it possible to be installed for all users ( under /usr directory) as a start.

    Hoping to hear back from you.


    Filippo Squillace

    Hey @breneser ,

    Thanks for the feedback you are providing. I really appreciate it as I think there are quite few features we could gather from it.

    There is a lot to consider in your feedback as you are not describing just one issue only.
    I agree on some points although I want to describe few clarifications. Let's categorize the issues, in order to simplify the conversation, in the following points:

    1. Pearl is not a dotfiles manager; 2. Improve Pearl as package manager; 3) Make Pearl available in bpkg

    Please, let's focus only on 1) for these days for the moment.

    1) Pearl is not a dotfiles manager

    Most of the people deal with their dotfiles by creating their own git repository and make all the changes they want to do to it by simply using git only.

    Curently, you can still manage your dotfiles in the same way people are used to do it, but for making changes to them you need to do it outside Pearl.
    Pearl treats the git repo as a package that can be installed/removed/updated. This means you can still sync/pull data but the pushing process needs to be done outside the Pearl system itself.

    It is perfectly achievable to give the user the full power of dealing with push or any additional git commands by introducing a new Pearl command called git, such as:

    pearl git <pkgname> <git args>

    So, to get the diff change, commit and push for the vimrc package you simply can run:

    pearl git vimrc diff
    pearl git vimrc commit -a -m 'New change'
    pearl git vimrc push origin master

    The user does not need to know a new syntax as it would be the same as git. This would cover the main VCSH functionality and Pearl would have a superset of functionalities that VCSH has.

    Moreover, you could even specify a git operation for all the packages. For instance, to see the status of all packages (for checking not staged commits):

    pearl git all status

    I am going to create an issue for that. It is not hard to do a basic implementation for it. If you have time, feel free to create a pull request I could help on creating unit tests and documentation.

    Bren Eser


    Thanks for the reply.

    I don't actually say Pearl is not a dotfiles manager. I just thought it wasn't quite fit for my requirements. And it worked much better for me as a package manager.

    So,what I understand is, your created Pearl as a package manager with dotfiles management features? Just asking to understand how you see it to be on the same page.

    If that is so, then I can give you feedback on why I couldn't use Pearl as a dotfiles manager which if you liked, you could use to define problem the domain.
    Bren Eser

    I agree your suggestion improves Pearl as dotfiles manager, but this alone would not quite cover VCSH functionality.

    Because Pearl keeps repos under a folder structure which would still mean linking to appropriate configuration folders. Which is what made me move away from Pearl as dotfiles manager. Because linking has certain limitations which makes it not simple to have certain functionalities I needed (Happy to share those needs if you would be interested.) VCSH creates fake bare git repos to allow multiple repos to track same folder ($HOME). Which solved a lot of issues I had.

    I guess before helping with improving I am just trying to better understand the vision for Pearl. I am just not quire sure having Pearl as both a dotfile manager and package manager is a feasible solution (that is just my humble opinion, happy to discuss further)

    On the other hand, I use Arch and Pacman to install packages, but then from time to time I use Ubuntu and others. The tools that exist on Github are not always available in package manager in use. Of course I can script installation and track those scripts, but I just saw Pearl's approach is much more generic and shareable, so those scripts can instead be Pearl wrapper repos I can create and let people install using Pearl.

    Filippo Squillace
    I just want to know more about the vcsh by making an example (as I see its doc a bit poor and could not fully understand how the trick works). If you have two separate vim dotfiles (maybe built by two different people) with different functions and/or key bindings and you want to benefit from both of them, how would you achieve that with vcsh?
    Bren Eser

    Well VCSH only handles tracking using git repos, it doesn't really do any application specific configuration handling like Pearl does (e.g. shell initialisation, vim, emacs, etc.) and yes it is really poorly documented.

    But inspired by Pearl I have put together simple scripts to achieve the same functionality ( a lot less mature atm). this repo which I use VCSH to track with only contains shell initialisation files to add Pearl-like functionality (.bashrc, .zshrc. Will add .vimrc as well), and all other repos I create have a similar structure to Pearl ( again tracked with vcsh). I call them oysters ( again inspired by Pearl, thank you :) ). One example is configuration for a headless basic environment or [xfce configuration] which I only install on xfce installed machines. So it is Pearl like dotfiles management without linking.

    When I said I think of creating a dotfiles manager based on VCSH, I had converting this base repository to a more generic project in mind (decoupled from .basrc, .zshrc and injecting it into them like Pearl does). That satisfies dotfiles management needs I have. That's why I moved away from Pearl for dotfiles management.

    Pearl is still useful for me though as a package manager as all git based tools have certain functionalities that needs shell init file configuration (e.g. bash completion, zsh completion and as such) and Pearl bundles those nicely.

    That's why I sounded a bit like I don't think Pearl is dotfiles manager, what I meant is just I don't use it for that purpose

    Bren Eser
    By the way, I don't mean to steal much of your time and I am not suggesting that you should do things my way. Just wanted to get a sense of which direction Pearl heads as in my mind I have dotfiles management and package management as two different concepts with some overlaying functionality.Of course Pearl can do both.
    Filippo Squillace
    I give a bit of history about Pearl for having more context. The initial idea about Pearl was indeed to have a convenient way to manage dotfiles across multiple machine. The linking functionality is part of the core Pearl (it is actually the main reason Pearl exist) as it allows to easily manage packages belonging to the same application i.e. you can combine different Pearl packages about vim and use them at the same time. This functionality is essential for most of the people (including me) that use Pearl atm. You could still use Pearl without linking too (it is fully optional, for instance without creating pearl-metadata directory) and in that case you could only install/remove/update the corresponding git repo of the Peal package in ~/.config/pearl/packages. Then, I realized that the Pearl package management (in other words install/remove/update/list and so on) combined with the linking functionality can actually allow to deal with any kind of applications and not just dotfiles. PearlHub already has quite a lot of applications in there. Currently, Pearl is a solution that covers most of the use cases (including my vision of dotfiles manager based on linking). Atm, it sounds true the fact that Pearl cannot cover your use case but it would be nice to find some sort of integration with the work you are currently doing in order to have a common solution that satisfy most of the people.
    Bren Eser
    @fsquillace Absolutely, Pearl still adds a lot of value to my workflow. I can maybe contribute to it from a package manager aspect of it?
    Filippo Squillace
    @breneser Thanks, only if you have time you may contribute to it. I think the most interesting issues are either the pearl git feature (which would allow to have a more advanced control over the installed package) or the one you created time ago: pearl-core/pearl#70 ; those will add values to the project IMHO. As I said, I can help with unit/integ testing and docs.