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.

Sign up for GitHub

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

Jump to bottom

Can't invoke non-build level keys #2707

Closed
dwijnand opened this issue Aug 23, 2016 · 5 comments
Closed

Can't invoke non-build level keys #2707

dwijnand opened this issue Aug 23, 2016 · 5 comments
Assignees
@Duhemm
Labels
Bug
Milestone
0.13.13

Comments

@dwijnand
Copy link
Member

dwijnand commented Aug 23, 2016 •
edited

steps

> show baseDirectory
[error] Ambiguous keys: {.}/*:baseDirectory, *:baseDirectory
[error] show baseDirectory
[error]                   ^
> show {.}/*:baseDirectory
[info] /s/t
> show *:baseDirectory
[error] Ambiguous keys: {.}/*:baseDirectory, *:baseDirectory
[error] show *:baseDirectory
[error]                     ^

problem

sbt suggests a key that doesn't work.

expectation

show *:baseDirectory should show the base directory.

notes

This is broken as of 0.13.12 and works in 0.13.11, so I have a feeling it might be due to #2469. /cc @Duhemm
@dwijnand dwijnand added the Bug label Aug 23, 2016
@eed3si9n
Copy link
Member

Yea, I'm getting this too using 0.13.13-SNAPSHOT:

foo> baseDirectory
[error] Not a valid command: baseDirectory
[error] Ambiguous keys: {.}/*:baseDirectory, *:baseDirectory
[error] baseDirectory
[error]              ^

@eed3si9n
Copy link
Member

So we should exclude build-level keys when there's a key that's scoped to project level?
This might make sense if we think in a multi-project example.

@dwijnand
Copy link
Member Author

Yeah project level should trump build-level. The original PR was just to add them to completion, but they shouldn't compete at the same priority.

@Duhemm
Copy link
Contributor

Duhemm commented Aug 24, 2016

What would be the correct behaviour then?

How about (for https://github.com/sbt/sbt/blob/0.13/main/src/main/scala/sbt/Act.scala#L79-L84):

  • If we have nothing, choose the default
  • If we have a single project level key and 0 or more build level keys, choose the project level key
  • If we have 0 project level keys and a single build level key, chose the build level key
  • If we have multiple possibilities, say that the key is ambiguous

@dwijnand
Copy link
Member Author

yep, sounds good.

Duhemm added a commit to Duhemm/sbt that referenced this issue Aug 24, 2016
@Duhemm
Fix key selection for build level keys
60bcc58 
PR sbt#2469 added build keys to tab completion, with the side effect of
considering as available candidate in key selection, thus making sbt
think that some inputs were ambiguous (e.g. `baseDirectory`): should it
apply to the current project or to the build level key?

This commit fixes this issue by improving the key selection:
 - If there's no candidate, we return the default key
 - If there's a single possible project level key, and zero or more
   build level keys, then we select the project level key.
 - If there are zero project level key, and a single build level key,
   then we select the build level key
 - If there are multiple candidates, sbt says that the input is
   ambiguous.

Fixes sbt#2707
@Duhemm Duhemm mentioned this issue Aug 24, 2016
Merged
@eed3si9n eed3si9n added this to the 0.13.13 milestone Aug 24, 2016
This was referenced Nov 29, 2016
Closed
Merged
eed3si9n added a commit to eed3si9n/sbt that referenced this issue Nov 30, 2016
@eed3si9n
Add build-level keys to the tab completion
00bab7b 
Fixes sbt#2460
Fixes sbt#2851
Ref sbt#2707, sbt#2708, sbt#2469

Unlike the previous attempts at fixing the handling of build-level
keys, this change does not change the main parsing logic, which uses
`getKey` to retrieve the key from the key map.
The fact that shell worked pre-0.13.11 means that the parsing was ok.

What this changes is just the "example" keys supplied to the parser so
the tab completion works.
@eed3si9n eed3si9n mentioned this issue Nov 30, 2016
Merged
eed3si9n added a commit to eed3si9n/sbt that referenced this issue Jan 16, 2017
@eed3si9n
Add build-level keys to the tab completion
90d9a80 
Fixes sbt#2460
Fixes sbt#2851
Ref sbt#2707, sbt#2708, sbt#2469

Unlike the previous attempts at fixing the handling of build-level
keys, this change does not change the main parsing logic, which uses
`getKey` to retrieve the key from the key map.
The fact that shell worked pre-0.13.11 means that the parsing was ok.

What this changes is just the "example" keys supplied to the parser so
the tab completion works.
@eed3si9n eed3si9n mentioned this issue Jan 16, 2017
Merged
eed3si9n added a commit to eed3si9n/sbt that referenced this issue Jan 16, 2017
@eed3si9n
Add build-level keys to the tab completion
569e19d 
Fixes sbt#2460
Fixes sbt#2851
Ref sbt#2707, sbt#2708, sbt#2469

Unlike the previous attempts at fixing the handling of build-level
keys, this change does not change the main parsing logic, which uses
`getKey` to retrieve the key from the key map.
The fact that shell worked pre-0.13.11 means that the parsing was ok.

What this changes is just the "example" keys supplied to the parser so
the tab completion works.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Duhemm Duhemm

Labels
Bug
Projects
None yet
Milestone
0.13.13
Development

No branches or pull requests
3 participants
@eed3si9n @dwijnand @Duhemm