Feature request: config files

[pjeby]

Now that we have BASHER_PREFIX and such, it'd be nice to be able to set it, especially systemwide. Perhaps we could have basher source /etc/basher.conf and ~/.basherrc if they exist, in that order. Then people like me could have a systemwide /etc/basher.conf that said something like:

if test `id -u` == "0"; then
    # customize these to sysadmin taste
    BASHER_PREFIX=/usr/local
    BASHER_PACKAGES_PATH=/usr/local/basher-packages
else
    # also customized to taste; can be overridden by user in ~/.basherrc
    BASHER_PREFIX="$HOME"
    BASHER_PACKAGES_PATH=~/.basher-packages
fi

This would let a globally-installed basher work for both end users and root; sudo basher install would install a package globally, and regular basher install would work locally. This would be a big step towards making basher usable as a system-level packaging tool, rather than just a personal one. (i.e., there's just one global install of basher as a program, even if individual users and the system have their own package directories.)

[juanibiapina]

What's stopping you from already doing this using your own dotfiles and /etc/profile ?

[pjeby]

Nothing. It's just nice to have application-specific files rather than editing generic profile files. Also, the files only need to be read by basher rather than being part of the general environment. I suppose system packagers could add a basher.sh or whatever to /etc/profile.d/, but it just seems to make more sense to have basher load the files when needed, rather than to put overhead on logins when, well, only basher is ever going to need them and you don't run basher all day long. (Well, I don't, anyway. 😄 )

[juanibiapina]

I see your point, but I think this whole system is in place exactly for this purpose. If basher can be configured using only environment variables, then I think we should stick to using them the way shell profiles are meant to be (if I'm not mistaken here).

I've seen some other packages that have their own configuration files, but they either have extra stuff which is not env variables, or just have a ton of configuration. Basher has only a couple and nothing out of the ordinary, so I find it easier to customize it with default systems tools.

Also, less code to test and maintain.

[pjeby]

In that case, maybe some more documentation? A big part of my thoughts on this was that by having its own config files and a more generally-compatible layout for users' home directories, it might be possible to encourage system packagers (Fedora, Debian, et al) to include basher as a system tool, so that people wouldn't need to manually install it.

[juanibiapina]

These are all very good points, but I don't think we're in that stage yet. User base is really small, and for now it solves the problems it proposes to solve.

[pjeby]

Fair enough. In my case, since the time I originally opened the issue, I've whipped up some bootstrapping code for my projects that locally installs basher within a project directory, configured to install everything local to that project directory (a bit like bpkg's local installs).

So, between that and some other tools I'm still finishing, people won't need to have basher installed in order to use or work on my projects. Which means evangelizing basher as a globally-available tool is no longer as high on my own priorities, either. :)

[juanibiapina]

Why do you need basher installed within project directories?

[pjeby]

So that people don't have to install it to work on the project.

Installing basher according to its default instructions is 1) invasive (i.e. requiring edits to shell config files), 2) painful (see point 1), and 3) requires buy-in by the user (to the preceding points, not to mention the odd default directory layout).

And all of those things are a burden on users who might otherwise contribute to a project, not to mention blockers for potential users to use a project that requires installation by basher!

That's why I originally focused on creating the BASHER_PREFIX stuff: to make it possible to install basher globally with a less-invasive, more-conventional layout. (And why I opened this issue.)

But as it happens, that same ability to customize the installation scheme makes it possible to do a project-local install of dependencies (ala bpkg local installs), which makes installing basher itself in that same local .deps/bin a reasonable thing to do. The actual use of basher is masked behind Scripts to Rule them All, so someone working on a project doesn't even have to know basher is involved, let alone edit any shell config files.

In addition, I've built a tool called bashpackr (not yet released, but you can see a draft of the docs here), that embeds sourced scripts into a single-file distribution, so that even if a project is built using basher installation of dependencies, it can still be distributed as a single shell script, allowing users to simply copy it to their PATH, bypassing the need for basher as a distribution method.

Basically, as awesome as basher is for development, needing to convince other people to use it to install or work on my projects is a complete non-starter. And while I originally thought it could be fixed by changing basher's default installation layout and encouraging system packagers to add it, I've since realized that a faster solution is just to install it as part of post-checkout bootstrapping of development work on a project, and build single-file distributables that don't need a package manager.

[juanibiapina]

I see, so you're trying to use it as a package manager more like bundler. This is a use case I wanted to support in the beginning, but ended up not doing it.

[pjeby]

I'm not sure what bundler is, but here's .devkit, which is what wraps up a local basher for installing development-time dependencies. It doesn't bundle anything, it's just for making a portable development environment, so that others working on your code automatically get what they need in a .deps subdirectory, without affecting anything outside the project directory.

[juanibiapina]

That's interesting. I'll leave basher as a global package manager for now, but this is something to consider in the future.

Let me know how your experience with devkit goes.

[kadaan]

@pjeby This is the same reason I have interest in basher.

But as it happens, that same ability to customize the installation scheme makes it possible to do a project-local install of dependencies ...

[juanibiapina]

Being a dependency manager for development was indeed one of the original goals of basher, but I dropped it once it became too difficult to have it both as a dependency manager and a global package manager while maintaining a sane code base. One key factor that influenced my decision at the time was the example on how npm is a complete mess while rubygems and bundler work so well together.

Since I didn't have a clear vision how to accomplish this, and wanted to at least get basher in a state that I could consider done, I went for global only.

If we're to make it work also as a per project dependency manager, we need to take care that each step is simple, sane and clean.

Having said that, reading a file that defines some env variables just for basher seems like a good idea overall.

[kadaan]

@juanibiapina FYI, I want to use basher as runtime dependency management tool.