Pharo Launcher cmd line should allow to work in current working directory

[demarey]

By default, Pharo Launcher cmd line uses the standard image repository to store the newly created image when creating an image.
PL CLI could propose a (global) setting to do not use the image repository and by so, use the current working directory to host images.
It means image listing will probably only show one image but image creation and store could happen anywhere.

There is still one open question: do we store the image directly in the current folder or in a folder with the name of the image as Pharo Launcher already do?
I would favor the second option since the creation of an image will also create a pharo.version file, a sources file a changes file, a meta-inf.stonfile, a pharo-local folder, etc. Having 2 images at the same place would not be possible.

@estebanlm WDYT?

[demarey]

@estebanlm What do you think of the proposition?

[guillep]

By default, Pharo Launcher cmd line uses the standard image repository to store the newly created image when creating an image. PL CLI could propose a (global) setting to do not use the image repository and by so, use the current working directory to host images.

Why a global setting?
Why not also a CLI flag

$ pl image create titi --here

It means image listing will probably only show one image but image creation and store could happen anywhere.

There is still one open question: do we store the image directly in the current folder or in a folder with the name of the image as Pharo Launcher already do? I would favor the second option since the creation of an image will also create a pharo.version file, a sources file a changes file, a meta-inf.stonfile, a pharo-local folder, etc. Having 2 images at the same place would not be possible.

My take, as a heavy user of command line with Pharo, is that I don't care, but this has some impact on other decisions:

• should the launcher be able to launch images from a directory name?
• launching that image should have the current working directory as working directory and not the image directory (as in the graphical mode) (is this the case already?)
• Also, what if there is a naming conflict between the global repository and the local working directory?

[demarey]

Thank you for the feedback @guillep.

By default, Pharo Launcher cmd line uses the standard image repository to store the newly created image when creating an image. PL CLI could propose a (global) setting to do not use the image repository and by so, use the current working directory to host images.

Why a global setting? Why not also a CLI flag

$ pl image create titi --here

Could be an option too. I thought a global option would be easier for people that do not want to work with a central image repository.

It means image listing will probably only show one image but image creation and store could happen anywhere.
There is still one open question: do we store the image directly in the current folder or in a folder with the name of the image as Pharo Launcher already do? I would favor the second option since the creation of an image will also create a pharo.version file, a sources file a changes file, a meta-inf.stonfile, a pharo-local folder, etc. Having 2 images at the same place would not be possible.

My take, as a heavy user of command line with Pharo, is that I don't care, but this has some impact on other decisions:

* should the launcher be able to launch images from a directory name?

in case of a global option, the current directory would be seen as the default image repository and by so, will be scanned to find folders with images inside. If there is only one, it will also work.
It will also allow to launch an image by giving the full path to an image.

* launching that image should have the current working directory as working directory and not the image directory (as in the graphical mode) (is this the case already?)

in CLI, this is the case.

* Also, what if there is a naming conflict between the global repository and the local working directory?

In my proposition, there will be no conflict because the global repository will be the local repository.

So, I think both options are open.
The best one would be the one that fits the most user needs: global option to avoid an extra flag at each command if the user always want to work locally, or a flag when user sometimes want to work locally