-
Notifications
You must be signed in to change notification settings - Fork 132
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
Reduce the number of characters needed for specifying which package is being selected #985
Comments
I wonder if this is something that needs to be implemented in spago itself? Terminals offer facilities to alias things to shorten them (after all we are not the first to have this issue), e.g. on linux/macos one can do
..so then one can always refer to that package with |
I think that would be a terrible UI. If I have 5+ projects (poly repo or not), you're saying I should define a single alias for each one of those? And I should update them if I ever rename those projects? Are there any stronger reasons against putting an alias in a If that were possible and I aliased |
A principle I apply often when dealing with things is "love the problem, not the solution". Before committing our minds to implementing a particular solution it is often worth exploring the problem space, as there might not even be a need implement anything in the first place. |
For example, it just occurred to me that - riffing on my previous idea of fuzzy matching package names - we could come up with matching abbreviations for hyphened names. So e.g. I prefer some other approach (like this fuzzy matching) over adding a configuration value because:
|
Ah, sorry. I didn't realize you were just brainstorming ideas in response to what I had proposed. Instead, I read it as you implicitly saying no and instead suggesting a different way to solve the problem. So far, we've identified the following design questions:
Where the current ideas breakdown as:
Within Idea 1 are shell aliases or some custom scripts someone could write (e.g. Idea 2 has already been described but there's another thing that would need to be done. In the event that two packages have the same unique alias (e.g. due to a copy-pasting a Idea 3 works likely 90% of the time but can be unpredictable. Take Unless there's another way this could be done or another issue I'm not considering, I still think Idea 2 has the current best tradeoffs. |
@f-f Any new thoughts on this and whether to support this? |
Yeah, I would like to support this. I am still of the opinion that idea3 has the better tradeoffs as it would work out of the box for everyone without need for configuration ("no need for configuration" is one of the reasons why people prefer esbuild over webpack, and it's one of Spago's north stars. The "automatic package discovery" for monorepos is on this same vibe). I don't think "adding a new package with a clashing name" is a big concern - we'd recommend people to not use the short aliases in scripts, in the same way that we recommend people to not use branches as git refs. |
I agree about the lack of configuration being a selling point. If my assumption about the probability of 2 or more packages having the same fuzzy match value is correct, then this might be a moot point. Even coming up with my example was hard. That being said, there is a better example worth considering. If we are going to migrate all of the core libraries into a single repo (and the same for Contrib, Node, and Web libraries), where would the current idea of a fuzzy matcher fail? I also wonder if we could further specify the fuzzy matching idea to decrease the probability of duplicates like that happening. I did some searching and via a StackOverflow answer found the post, Comparison of String Distance Algorithms. |
These are good finds. I'm not sure though that this is a typical example of fuzzy matching: the interface for the examples you linked is interactive, so the user can see how the search is performing while they are typing something. UI-wise, I was thinking we'd show the aliases to the user when they type in any command that lists the packages, e.g.: $ spago build
Refreshing the Registry Index...
Reading Spago workspace configuration...
Read the package set from the registry
✅ Selecting 4 packages to build:
docs-search (alias: ds)
spago (alias: s)
spago-bin (alias: sb)
spago-core (alias: sc) Edit: I'm cursed with a terrible memory so I am not sure where I've seen this "shorten words to their first letters" kind of algorithm - though I'm sure I've seen it used before. It reminds me of Huffman coding and prefix trees, but it's far from either. |
Exploring your idea of how this would work for core: I got the list of all the repos that might be purescript libraries (there are some spurious results, but bare with me): $ gh repo list purescript -L 100 | grep "purescript-" | cut -d' ' -f1 | cut -f1 | sed "s|purescript/purescript-||g" | sort
arrays
assert
bifunctors
catenable-lists
console
const
contravariant
control
datetime
distributive
docs-search
effect
either
enums
exceptions
exists
filterable
foldable-traversable
foreign
foreign-object
free
functions
functors
gen
graphs
identity
in-purescript
integers
invariant
json
lazy
lcg
lists
maybe
metadata
minibench
newtype
nonempty
numbers
ordered-collections
orders
parallel
partial
prelude
profunctor
psci-support
quickcheck
random
record
refs
safe-coerce
semirings
st
strings
tailrec
transformers
tuples
type-equality
typelevel-prelude
unfoldable
unsafe-coerce
validation Shortening these with the algorithm I proposed would give us:
This list has some pretty juicy corner cases, so it's a very good candidate for writing a test once we implement this 🙂 |
There would be a fuzzy-matching part too - if the user would type |
I was typing this as you responded with the two comments above. Given the above list, I'm not sure how useful it would be now that we have some hard data. But I'll still post it. How about this implementation? It's predictable, reduces the character count, and is flexible in how explicit one wants to be. A user-inputted text matches a package name if, after splitting the user-input text and package name text into segments whenever a
Prefix/Suffix check. A user-inputted segment is further split via a Here are a few examples of the idea:
This is simple to implement now without the need for additional libraries. Implementing things this way encourages the following:
The combination of the segment length check and support for both prefix/suffix checks can help address my concern about how adding a new package could invalidate a command used elsewhere because the aliased package name there is no longer unique. In other words Using BNF grammar:
|
I think having to deal with characters like |
Ah, I forgot about Another way we could address my concern about commands changing is adding a command for creating a new subpackage. When this is done, we could also check to see which aliases will need to be changed once the new subpackage is added. |
Ah yes, would be nice to have a |
Have shell completions been considered as a solution? Git ships with shell completions which helps with switching between branches that may be long. I looked at the readme for spago, and noticed it already has a section on generating completions. This lead me to discovering that https://github.com/f-o-a-m/purescript-optparse#actions-and-completers So theoretically we could make the The user could type spago build -p uncopy<tab> and have that expand to spago build -p uncopyrightable-sesquipedalian-package |
That works so long as the shell supports that kind of completion, right? Like does this work on bash, sh, fish, zsh, and whatever other shell will come along? Or does it need special support for each of those shells? If the former, then this sounds like the better solution (though I'm not sure how much work that would be). If the latter, than I think Fabrizio's idea is still better. |
This works on bash, zsh and fish, but it requires manual installation. I don't know if we can do it with npm or nix, but I'm afraid it will have to be manual. It's also not always clear how to install these actually - the readme documents the way I managed to install shell completions myself, but there might be a more reliable one. In any case, this fits under the box "it's not enabled by default but a user has to", which hurts the convenience. I'm fine with implementing both avenues at this point. |
The new spago's CLI allows one to select a package by referring to it via package name. However, this choice is somewhat problematic in a few situations:
node-some-special-package-name
) or due to long words within the name (e.g.uncopyrightable-sesquipedalian-package
courtesy of 13 of the Longest Words in the English Languagei
ando
in-tion
)I propose we make it possible to reduce the number of character used. There are a few ways to do this:
spago.yaml
, add a new fieldcli-alias
in thepackage
section that allows one to use that alias string in addition to the package name. Given a package nameuncopyrightable-sesquipedalian-package
and an aliaslib
, bothspago install -p uncopyrightable-sesquipedalian-package
andspago install -p lib
modify the same package's dependencies).Of these two, I prefer the first one.
The text was updated successfully, but these errors were encountered: