On 03/09/18 14:43, Sander Striker
wrote:
Hi,
I think myself and
Tom agreed with Sanders last remarks so we have been a bit
slow in responding.
As Tristan has been quite on this I amuse he is similarly
minded, if not if he could reply sooner rather than later
then it will avoid myself and tom codeing this up and then
having a too lengthy MR rework.
I have made some notes further down as well.
Responses inline.
Thanks All
Will
PS. Tristan i know you are supper busy wit 1.2 atm but if
you could fine moment this week, as we will probs start
next week that would be really appreciated.
On 28/08/18 23:11, Sander Striker wrote:
> When opening a single element then you
can:
>
> bst workspace open --directory
/path/to/workspaces --multi
> elementA.bst elementB.bst
>
>
> Why do we need the --multi argument? That
doesn't seem intuitive. If
> it is to get around the fact that otherwise
elementB.bst would be
> interpreted as the workspacename, then I
don't think we should do that.
> Otherwise you end up with an open workspace
carrying the name of the
> second element you wanted a workspace open
for.
Yes it is to mitigate the situation you've
mentioned. Will has some
thoughts about handling this with click in
alternative ways, however as
it stands the most sane thing seemed to be the use
of an additional flag.
I'm opposed to the --multi flag. I don't think
it's intuitive.
I am definitely concerned about this invocation
in the current proposal resulting in:
$ bst workspace open elementA.bst elementB.bst
... opens up a workspace for elementA.bst in a
directory called
/path/to/workspaces/elementB.bst...
I think it makes more sense to in this case
make a backward incompatible change to the CLI,
for the benefit of a better user experience.
I read this as: we all dislike the --multi flag but we can
think of a better way?
So I think we are agreed to go with the --multi/-m flag.
It's beyond dislike. I really don't think we should do
that based on the example I've given above.
Sorry I miss read your previous response.
If were trying to avoid the chance of missing something and getting
miss named element then a really big change that would take a bit of
getting used to for people familiar with the old system but
hopefully clear to new people might be:
We could
change from:
bst
workspace open element.bst workspacename
to:
bst
workspace open [--directory /path/to/workspaces]
[[elementname.bst] ...] [[--named elementName.bst
workspaceName] ...]
This wold brake backwards api compatibility but would allow
flexibility going forwards.
maybe my use of [] is a bit unclear. I have write something in code:
import click
@click.command()
@click.option('--named', nargs=2, multiple=True,
help='a element and its custom name')
@click.argument('elements', nargs=-1)
def workspace_open(elements, named):
"""as many [elements] as you like and as many [--name element
customWorkspaceName] as you like"""
print(elements)
print(named)
if __name__ == '__main__':
workspace_open()
giving:
$python3 testclick.py build.bst --named thing.bst place
('build.bst',)
(('thing.bst', 'place'),)
This is the cleanest thing I can come up with that dose not have a
option for multi elements but also allows for custom workspace
names, however it is quite different to the original and is a bit
messy.
We can call the --named option what ever we like.
Another good thing about this is if we check all the elements were
going to make workspace for exists before we start making them then
if some one tries to do the old way under the new way we can catch
it and not make anything that the user didn't want eg.
$bst open workspace element.bst newname
would check if `newname` is a element and raise a error without
doing anything unexpected..
This seems like a nice selling point to me.
[...]
> What is the recovery mode for a moved
workspace that can't find its
> project? Can it be re-registered?
Will mentioned that a user could 'fudge' the path
given in a workspace
fragment which would allow for manual intervention
in the case of
re-registering. Ultimately that's a bit messy so
going forward with a
utility (a new flag for bst workspace?) for the
re-association of
workspaces to projects is probably the right thing
to do.
+1. I don't really like the idea that we end
up with an FAQ that tells you to edit the
'fragment'.
How 'smart'
this command would be, especially when trying to
generate a list of
potential parent projects, is something that would
need to be more
fleshed out if desired.
I think we'll be ok if we ask for confirmation
to replace all associations with just the
association to this single project.
I feel like this is a
lot of effort when we could just say "we don't support
moving projects", just clone/copy the project with out the
.bst folder and set up new workspaces your self.
That said if we want a mover utility function/tidier its
not a lot of effort so we could easily right it.
I prefer stating that we don't support moving over
suggesting someone "...could 'fudge' the path given in a
workspace fragment...".
I imagine from the user perspective this could look
something like:
$ cd $project_dir
$ bst workspace close --force $element.bst
$ bst workspace open --directory
/new/path/to/element/workspace $element.bst
which I think is acceptable. The individual workspace
commands should already be supported, unless I'm missing
something?
I was thinking we would recommend something along the lines of:
* close existing workspaces
* move the project
* open the workspaces you need.
for general moving
but also recommend your commends if something gets out of sink for
what ever reason.
I think we can do this more or less atm but we should insure that by
the time we have made these changes it all definitely works.
|
