Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Deprecate accessing subsystems directly at the root of the apx CLI #439

Open
acerspyro opened this issue Dec 16, 2024 · 2 comments

Comments

@acerspyro
Copy link

acerspyro commented Dec 16, 2024

TL;DR:

  • Avoid mixing dynamic and static elements in the apx commands to reduce confusion.
  • Recommend standardizing to a command action item format—transition from apx my-subsystem to apx enter my-subsystem and apx subsystems enter my-subsystem.
  • Propose deprecating direct dynamic access to ensure cleaner, more predictable usage, with proper notices about the deprecation.

This issue is a follow-up to issue #437 on GitHub, which was resolved by preventing users from creating subsystems with names that conflict with internal Apx commands.

It is unexpected for dynamic elements to share the same menu as static elements, as this can lead to confusion. A new user would likely look under apx subsystems to find their subsystems, rather than searching through a mix of existing static elements.

Having dynamic items as the first parameter to a CLI command is typically reserved for single-purpose commands that heavily rely on flags for other purposes, such as ls.

apx is more like git or npm in this regard, where it allows you to perform a lot of different actions in one command.

This feels like looking for a needle in a haystack:

veryloud@apx-vso-pico:~$ apx --help
Apx is a package manager with support for multiple sources, allowing you to install packages in subsystems.

Usage:
  apx [command]

Available Commands:
  completion  Generate the autocompletion script for the specified shell
  devel       Work with the specified subsystem, accessing the package manager and environment.
  help        Help about any command
  pkgmanagers Work with the package managers that are available in apx.
  stacks      Work with the stacks that are available in apx.
  subsystems  Work with the subsystems that are available in apx.
  ubuntu-dev  Work with the specified subsystem, accessing the package manager and environment.

Flags:
  -h, --help      Show help for apx.
  -v, --version   Show version for apx.

Use "apx [command] --help" for more information about a command.

Here's a parallel:
it would be unexpected for Git to allow access to a branch by typing git my-branch-name, as this could conflict with git's internal commands.

Users expect to write their commands in the following format:

command action item

I suggest instead using apx enter my-subsystem, which follows this expected pattern and still provides a shortcut to quickly enter a subsystem, alongside an apx subsystems enter my-subsystem, which puts a command both in the expected location and within a shortcut.

Other examples of commands that follow this pattern include:

  • apt install package-name
  • abroot pkg add package-name (where pkg is a sub-command and add is the action)
  • npm run my-npm-command

And examples that are usually, but not necessarily, typed in this fashion:

  • ls -la ./folder
  • rm -rf ./file

This will bring on some backwards-compatibility concerns, so I suggest we:

  • Keep the existing fix
  • Deprecate accessing subsystems directly as a root parameter to apx
  • Mention the feature and its deprecation in the --help menu.
  • Mention the deprecation in the command line when a subsystem is accessed in this fashion.
@acerspyro acerspyro changed the title Feature: Allow selecting subsystems from the "subsystems" CLI menu Feature: Deprecate accessing subsystems directly at the root of the apx CLI Dec 16, 2024
@taukakao
Copy link
Member

Please add a tl;dr at the start of the issue for long issue descriptions like this.

@acerspyro
Copy link
Author

Please add a tl;dr at the start of the issue for long issue descriptions like this.

Good idea, done, thx!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants