Iceberg - better control of project name?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Iceberg - better control of project name?

Tim Mackinnon
Hi - I’ve just noticed a small issue with the latest iceberg - or at least its confusing. The Exercism project - is in a repo specified by them - its exercism/pharo.git

And when I check it out using the latest iceberg using the GitHub option - I specify an Owner of “exercism” and a project name “pharo” to get it to properly check out. However in the iceberg window this then appears as a project called “pharo” which is very misleading when there is the master “Pharo” project for all of pharo. (See photo)

There doesn’t seem to be a way to override the display of this name to make it “exercism/pharo” - and I’m wondering if Iceberg should handle this a bit better - either by showing {owner}/{project} or letting you give a better name in the definition to override what is shown?

Tim

Reply | Threaded
Open this post in threaded view
|

Re: Iceberg - better control of project name?

Ben Coman
Having also worked with the Exercism-Pharo project I've had the same thoughts.  
Its a bit like from the command line specifying which directory is created.
    git clone  <repository> [<directory>]

cheers -ben

On Sat, 29 Sep 2018 at 12:34, Tim Mackinnon <[hidden email]> wrote:
Hi - I’ve just noticed a small issue with the latest iceberg - or at least its confusing. The Exercism project - is in a repo specified by them - its exercism/pharo.git

And when I check it out using the latest iceberg using the GitHub option - I specify an Owner of “exercism” and a project name “pharo” to get it to properly check out. However in the iceberg window this then appears as a project called “pharo” which is very misleading when there is the master “Pharo” project for all of pharo. (See photo)

There doesn’t seem to be a way to override the display of this name to make it “exercism/pharo” - and I’m wondering if Iceberg should handle this a bit better - either by showing {owner}/{project} or letting you give a better name in the definition to override what is shown?

Tim


PastedGraphic-2.png (258K) Download Attachment
PastedGraphic-2.png (258K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Iceberg - better control of project name?

Sean P. DeNigris
Administrator
In reply to this post by Tim Mackinnon
Tim Mackinnon wrote
> either by showing {owner}/{project}

What about when there are multiple remotes?


Tim Mackinnon wrote
> letting you give a better name in the definition to override what is
> shown?

We have project metadata now, so that seems straightforward. I have a few
use cases where the GH project name is "PharoXyz" or "AbcForPharo", which is
only added to clarify in a non-Smalltalk setting the actual name of the
project is different (usually omitting "Pharo").



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Iceberg - better control of project name?

Ben Coman


On Mon, 1 Oct 2018 at 23:16, Sean P. DeNigris <[hidden email]> wrote:
Tim Mackinnon wrote
> either by showing {owner}/{project}

What about when there are multiple remotes?

+1 to what you imply here, that the owner/remote should not be auto-coded into the project name.
Remote are well handled within Iceberg.
The user though could add the owner as free text into a custom project name i.e. "owner-project"

cheers -ben
 
Reply | Threaded
Open this post in threaded view
|

Re: Iceberg - better control of project name?

Tim Mackinnon
Sounds like the user override is what we are after - I guess we need to make a pr ... sadly my laptop has died so it’s not going to be me for a little while until I can find an Apple store on my travels.

Tim

Sent from my iPhone

On 2 Oct 2018, at 12:30, Ben Coman <[hidden email]> wrote:



On Mon, 1 Oct 2018 at 23:16, Sean P. DeNigris <[hidden email]> wrote:
Tim Mackinnon wrote
> either by showing {owner}/{project}

What about when there are multiple remotes?

+1 to what you imply here, that the owner/remote should not be auto-coded into the project name.
Remote are well handled within Iceberg.
The user though could add the owner as free text into a custom project name i.e. "owner-project"

cheers -ben
 
Reply | Threaded
Open this post in threaded view
|

Re: Iceberg - better control of project name?

Guillermo Polito
Yes, I agree with most of the comments here. I'll try to summarize:

 - we should be able to specify the name of a project independently of their location/repository name
 - Maybe, for old projects that don't have a name, we could initialize a project's name as it's repository name?

On Tue, Oct 2, 2018 at 5:07 AM Tim Mackinnon <[hidden email]> wrote:
Sounds like the user override is what we are after - I guess we need to make a pr ... sadly my laptop has died so it’s not going to be me for a little while until I can find an Apple store on my travels.

Tim

Sent from my iPhone

On 2 Oct 2018, at 12:30, Ben Coman <[hidden email]> wrote:



On Mon, 1 Oct 2018 at 23:16, Sean P. DeNigris <[hidden email]> wrote:
Tim Mackinnon wrote
> either by showing {owner}/{project}

What about when there are multiple remotes?

+1 to what you imply here, that the owner/remote should not be auto-coded into the project name.
Remote are well handled within Iceberg.
The user though could add the owner as free text into a custom project name i.e. "owner-project"

cheers -ben
 


--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: Iceberg - better control of project name?

Guillermo Polito
Aaand the mail got sent before :)

Then two other comments that are related or I'd like to discuss:
  - So far we can allow in iceberg several projects with the same name. That is not a problem, so you can clone the same project from two different repositories. Of course this would mean that one will be dirty all the time (in comparison against the image).
  - I'd like to "rethink" the directory structure. We have chosen to use {owner}/{repository} for some time now, but that is only valid for those hostings that store repositories under a username (e.g., github/gitlab/bitbucket) and is not valid for other kind of git hostings/server (e.g., a home gitolite).
    This makes that the directory where the repositories are, suddenly mixes different structures {owner}/{repository} and {repository}, and we pay that lack of coherence afterwards... But making a purely flat structure will cause much more name clashes. And there is some story with Metacello compatibility around it too!
    I'm just not sure what is the bestish solution here. Maybe what we have is good enough, but if somebody would like to prototype around this, I'd be glad to learn more about pros and cons ^^.

On Tue, Oct 2, 2018 at 9:51 AM Guillermo Polito <[hidden email]> wrote:
Yes, I agree with most of the comments here. I'll try to summarize:

 - we should be able to specify the name of a project independently of their location/repository name
 - Maybe, for old projects that don't have a name, we could initialize a project's name as it's repository name?

On Tue, Oct 2, 2018 at 5:07 AM Tim Mackinnon <[hidden email]> wrote:
Sounds like the user override is what we are after - I guess we need to make a pr ... sadly my laptop has died so it’s not going to be me for a little while until I can find an Apple store on my travels.

Tim

Sent from my iPhone

On 2 Oct 2018, at 12:30, Ben Coman <[hidden email]> wrote:



On Mon, 1 Oct 2018 at 23:16, Sean P. DeNigris <[hidden email]> wrote:
Tim Mackinnon wrote
> either by showing {owner}/{project}

What about when there are multiple remotes?

+1 to what you imply here, that the owner/remote should not be auto-coded into the project name.
Remote are well handled within Iceberg.
The user though could add the owner as free text into a custom project name i.e. "owner-project"

cheers -ben
 


--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13



--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: Iceberg - better control of project name?

Guillermo Polito

On Tue, Oct 2, 2018 at 10:02 AM Guillermo Polito <[hidden email]> wrote:
Aaand the mail got sent before :)

Then two other comments that are related or I'd like to discuss:
  - So far we can allow in iceberg several projects with the same name. That is not a problem, so you can clone the same project from two different repositories. Of course this would mean that one will be dirty all the time (in comparison against the image).
  - I'd like to "rethink" the directory structure. We have chosen to use {owner}/{repository} for some time now, but that is only valid for those hostings that store repositories under a username (e.g., github/gitlab/bitbucket) and is not valid for other kind of git hostings/server (e.g., a home gitolite).
    This makes that the directory where the repositories are, suddenly mixes different structures {owner}/{repository} and {repository}, and we pay that lack of coherence afterwards... But making a purely flat structure will cause much more name clashes. And there is some story with Metacello compatibility around it too!
    I'm just not sure what is the bestish solution here. Maybe what we have is good enough, but if somebody would like to prototype around this, I'd be glad to learn more about pros and cons ^^.

On Tue, Oct 2, 2018 at 9:51 AM Guillermo Polito <[hidden email]> wrote:
Yes, I agree with most of the comments here. I'll try to summarize:

 - we should be able to specify the name of a project independently of their location/repository name
 - Maybe, for old projects that don't have a name, we could initialize a project's name as it's repository name?

On Tue, Oct 2, 2018 at 5:07 AM Tim Mackinnon <[hidden email]> wrote:
Sounds like the user override is what we are after - I guess we need to make a pr ... sadly my laptop has died so it’s not going to be me for a little while until I can find an Apple store on my travels.

Tim

Sent from my iPhone

On 2 Oct 2018, at 12:30, Ben Coman <[hidden email]> wrote:



On Mon, 1 Oct 2018 at 23:16, Sean P. DeNigris <[hidden email]> wrote:
Tim Mackinnon wrote
> either by showing {owner}/{project}

What about when there are multiple remotes?

+1 to what you imply here, that the owner/remote should not be auto-coded into the project name.
Remote are well handled within Iceberg.
The user though could add the owner as free text into a custom project name i.e. "owner-project"

cheers -ben
 


--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13



--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13



--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: Iceberg - better control of project name?

Ben Coman
In reply to this post by Guillermo Polito


On Tue, 2 Oct 2018 at 15:52, Guillermo Polito <[hidden email]> wrote:
 - Maybe, for old projects that don't have a name, we could initialize a project's name as it's repository name?

In any case, I'd expect the project name within Iceberg to match the name of the working directory on disk.
Possibly even the project renamed within Iceberg should rename the disk working directory.
(btw, I don't know if "project name" is the best term, but I can't think of a better one.)

cheers -ben
 

On Tue, Oct 2, 2018 at 5:07 AM Tim Mackinnon <[hidden email]> wrote:
Sounds like the user override is what we are after - I guess we need to make a pr ... sadly my laptop has died so it’s not going to be me for a little while until I can find an Apple store on my travels.

Tim

Sent from my iPhone

On 2 Oct 2018, at 12:30, Ben Coman <[hidden email]> wrote:



On Mon, 1 Oct 2018 at 23:16, Sean P. DeNigris <[hidden email]> wrote:
Tim Mackinnon wrote
> either by showing {owner}/{project}

What about when there are multiple remotes?

+1 to what you imply here, that the owner/remote should not be auto-coded into the project name.
Remote are well handled within Iceberg.
The user though could add the owner as free text into a custom project name i.e. "owner-project"

cheers -ben
 


--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: Iceberg - better control of project name?

Sean P. DeNigris
Administrator
Ben Coman wrote
> I'd expect the project name within Iceberg to match the name
> of the working directory on disk.

I wonder if e.g. direct git loading creating a directory with the same name
as the repo (and maybe not what you'd want to see in Pharo) would make that
potentially problematic. Maybe that's an artificial limitation? Not sure,
just musing...



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Iceberg - better control of project name?

Guillermo Polito
In reply to this post by Ben Coman


On Tue, Oct 2, 2018 at 6:54 PM Ben Coman <[hidden email]> wrote:


On Tue, 2 Oct 2018 at 15:52, Guillermo Polito <[hidden email]> wrote:
 - Maybe, for old projects that don't have a name, we could initialize a project's name as it's repository name?

In any case, I'd expect the project name within Iceberg to match the name of the working directory on disk.

Yes
 
Possibly even the project renamed within Iceberg should rename the disk working directory.

I am afraid of this ^^. This could be a natural and simple mechanism to explain, but take into account that you can have in iceberg different repositories from different places in your disk.
Then this means you will not be able to rename your project if you have a directory with the required name in the same place.
 
(btw, I don't know if "project name" is the best term, but I can't think of a better one.)

cheers -ben
 

On Tue, Oct 2, 2018 at 5:07 AM Tim Mackinnon <[hidden email]> wrote:
Sounds like the user override is what we are after - I guess we need to make a pr ... sadly my laptop has died so it’s not going to be me for a little while until I can find an Apple store on my travels.

Tim

Sent from my iPhone

On 2 Oct 2018, at 12:30, Ben Coman <[hidden email]> wrote:



On Mon, 1 Oct 2018 at 23:16, Sean P. DeNigris <[hidden email]> wrote:
Tim Mackinnon wrote
> either by showing {owner}/{project}

What about when there are multiple remotes?

+1 to what you imply here, that the owner/remote should not be auto-coded into the project name.
Remote are well handled within Iceberg.
The user though could add the owner as free text into a custom project name i.e. "owner-project"

cheers -ben
 


--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13



--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: Iceberg - better control of project name?

Ben Coman
On Wed, 3 Oct 2018 at 16:18, Guillermo Polito <[hidden email]> wrote:
 
 
On 2 Oct 2018, at 12:30, Ben Coman <[hidden email]> wrote:
On Mon, 1 Oct 2018 at 23:16, Sean P. DeNigris <[hidden email]> wrote:
Tim Mackinnon wrote
> either by showing {owner}/{project}

What about when there are multiple remotes?

+1 to what you imply here, that the owner/remote should not be auto-coded into the project name.
Remotes are well handled within Iceberg.
The user though could add the owner as free text into a custom project name i.e. "owner-project"

cheers -ben

 
On Tue, Oct 2, 2018 at 6:54 PM Ben Coman <[hidden email]> wrote:


On Tue, 2 Oct 2018 at 15:52, Guillermo Polito <[hidden email]> wrote:
 - Maybe, for old projects that don't have a name, we could initialize a project's name as it's repository name?

In any case, I'd expect the project name within Iceberg to match the name of the working directory on disk.

Yes
 
Possibly even the project renamed within Iceberg should rename the disk working directory.

I am afraid of this ^^. This could be a natural and simple mechanism to explain, but take into account that you can have in iceberg different repositories from different places in your disk.
Then this means you will not be able to rename your project if you have a directory with the required name in the same place.

I get your point, and Sean's also.  Probably over-constraining it to force the Pharo-name and disk-name to be the same.
It would help if the disk working directory is easily discoverable, like showing in a hover popup.
Menu items like "Open Folder Here" or "Open Shell Here" would help workflow.

cheers -ben