config.yaml#cabals erased when passing key to cli
tomquas opened this issue · comments
hey, i was wondering whether it is intentional that all cabals are replaced with the one provided on the command line when doing
$ cabal cabal://f4...c2
config.yaml before running cli:
aliases:
cabal.club: 508fdfb25cc892e4ea32fe01be1a0d8cddd2a8bafae30aaf667446b1cdb220b9
cabals:
- 508fdfb25cc892e4ea32fe01be1a0d8cddd2a8bafae30aaf667446b1cdb220b9
cache: {}
config.yaml after running cli:
aliases:
cabal.club: 508fdfb25cc892e4ea32fe01be1a0d8cddd2a8bafae30aaf667446b1cdb220b9
cabals:
- 'cabal://f4...c2'
cache: {}
i understand you do want to make a distinction between '--join key' (lasting) and providing a key as cli argument (single session). right?
this comment seems to second this, but storing the single session cabal and erasing the lasting ones this code seems counter-productive. no?
let me know and i'll dig into this...
@tomquas you're right! fixing this would also fix #158.
the reason is historic, it's from when we implemented an experimental version of multi-cabal and then briefly patched it out, until it was properly reintroduced with cabal-client. additionally, over time we've added flags to the cli (as well as make it possible to run without flags) without also refactoring the semantics, so that's part of why things are contradicting each other
i understand you do want to make a distinction between '--join key' (lasting) and providing a key as cli argument (single session). right?
actually it's the reverse at the moment, --join is used to join only the specified cabal
thanks for the digging you've done already!
if you don't mind, i can take a hand at fixing this during the week and tag you in the resulting PR?