Various Features for Discussion

[halostatue]

Rather than opening direct feature requests, I thought I would start a discussion on some possible features that I’ve come across in trying to translate a large script I have into Bashly or have risen because of discussions on the other feature requests I have opened. I had a couple more ideas that would make it easier for users to hook into core Bashly functionality, but they’re not well formed and I don’t have a particular use case for them the way that I would these.

Private Flags

Right now, only (sub-)commands can be set to private: true and therefore hidden from documentation. This is useful, but occasionally I have flags on commands that I need to exist, but should not be used by default (either they are intended to be used by an internal re-invocation of the script or are options that are dangerous by default).

Conditionally Private Commands / Flags

The script that I’m building is one that I eventually want to have in a Homebrew formula for or a MacPorts port. I want to have some commands (cli self update and cli self destruct) that, if the script determines that it is running from a location not managed by the script itself (that is, it is running from /usr/local/bin instead of $HOME/.local/bin), those functions should be marked private and hidden from cli --help. I would obviously still need to have code in those core functions to treat them as invalid commands when they should be hidden, but this would be useful.

The spec for this wouldn’t be too hard to change, as it would be similar to command.default: if true or false, it’s static. If a string, it would be the name of a function which must be defined by the script author that could be called to test command or flag privacy at runtime.

It appears that the completion script uses the private flag to determine what would be included. In this case, I would suggest that private: String is treated as private: false.

Custom add Libraries

I’m likely to be converting a half-dozen scripts to Bashly, and it would be nice to be able to do something like:

# settings.yml
additional_libraries:
  - $HOME/.local/share/bashly/lib
  - https://github.com/halostatue/bashly-library

$ bashly add my-utils
# bashly cannot find `my-utils` in its builtins, so it searches through directories or possibly URLs in `Settings.additional_libraries`.

Sure, I can copy my existing library functions around, but it would be nice to have them in a repo for that purpose that extends Bashly’s add functionality. One key point: as Bashly is an opinionated tool, its defaults win. If I were to add a colors library file, it would not add that, but the built-in Bashly library. It would have to be named differently, such as my-colors.

[DannyBen]

All great ideas.

Private flags

Sounds reasonable and easy to implement.

Custom libraries

We will need to think about the discovery mechanism. I don't think the place for it is the Settings, since if you take the time to add them to the settings, you can just copy them instead - bashly add is a one-off command.

We probably need to come up with a convention, like BASHLY_CUSTOM_LIBS environment variable, or something.

Furthermore, it could be nice if there would be a bashly add --github me/myrepo/mylib or something like that to fetch and add libraries from a remote repo.

Conditional private

About this one, I am not sure. This sounds like quite a niche functionality - I cannot recall any command line interface that changes its usage based on environment arguments. Let the command appear in the usage, and add a filter or some other blocking logic if somebody is running it where they should not.

I am open to be convinced, but the implementation and accompanying documentation for such a feature must be simple and have a higher than minimal chance of being useful to more than 5% of users.

---

For the first two, we can open a feature request issue to track separately. Do you want to do it or should I?

[halostatue]

Done as #332 and #333.

For the conditional private, I think that there’s an alternate feature request that could be made which would enable this, and would probably be a little easier to implement in general.

1. Add a spec: key to settings.yml. This specifies which bashly spec to load (relative to source_dir). If omitted, it defaults to #{Settings.source_dir}/bashly.yml.
2. Add a --settings, -s (or --config, -c for normal convention) to bashly generate which chooses which settings.yml to read.

That way, I could do:

$ bashly generate
# generates the default script for standalone use
$ bashly generate -s package-settings.yml
# generates the package script with the optional commands omitted, possibly in a different `target_dir`.

Still a niche feature, but implemented in a way that shouldn’t complicate the overall Bashly implementation or the scripts involved, yet provides the functionality that I need.

I might be able to do this without direct support by having a package/ directory with its own src/bashly.yml and everything else symlinked, but that feels much more fragile.

[DannyBen]

Yeah, well this is definitely easier and with more use cases.

However, we distinguish between settings and config - which is the bashly.yml itself.
Also - since many bashly commands use these two files, I feel it is more appropriate to have them as environment variables and not CLI args:

• BASHLY_SETTINGS_PATH
• BASHLY_CONFIG_PATH

Will this work for you?

[halostatue]

I would prefer CLI args, but environment variables will work just fine, especially as I will wrap this in a Makefile for a release process.

[DannyBen]

#336

[DannyBen]

All features implemented, except the bashly add CUSTOM - which I need to think about.

Docker edge version was pushed, or if you want to test with the master branch, you also can.
https://github.com/DannyBen/bashly/tree/master/edge#readme