On Thu, Aug 9, 2018 at 11:18 AM Norbert Hartl <norbert@hartl.name> wrote:

Am 08.08.2018 um 14:12 schrieb Herbert Vojčík <herby@mailbox.sk>:

Damien Pollet wrote on 8. 8. 2018 13:53:

First of all, quick stupid question: I'm currently loading my code with gitlocal://./src as the repository URL (my workflow starts in a terminal rather than in a Pharo image) Should I just remove the /src part, now that my repo has the project metadata? Also, are more features planned for the .project file? E.g. what about storing a default selection for Calypso and the Test Runner in there? On Wed, 8 Aug 2018 at 10:28, Norbert Hartl <norbert@hartl.name < mailto:norbert@hartl.name <norbert@hartl.name>>> wrote: - I don’t think there can be a „standard way“ of defining source directory. And I don’t think that a tool should enforce this however. I keep frontend and backend code in some repositories together so the source is in my case in backend/source. What does it mean for users not using the „standard“ name? Sure there can. Look at any ruby or maven project, they all have strong conventions for organizing projects and standard config files for deviating from those conventions. I would have preferred if Iceberg picked one convention (arbitrarily) in the absence of a .project file instead of forcing its explicit presence. IMHO the choice of default directory per se (be it ./, ./src, ./source or whatever) matters less than the fact that there is a convention in place. - I don’t see why there needs to be a 1:1 relationship between a repository and working copy in pharo. It is like this at the moment already but the .project file manifests this. So it should not be supported to have more source dirs in one git repo? It might be not a good idea that the client has to write the source dir but it opens the possibility that there can be more than one. I see your point here, but by using separate source directories you're sort of creating a hydra project… What I mean here is that the source directories are separate, but their histories are tangled. If you want separate source dirs it kinda means that you want separate change histories, doesn't it? What if the same class has diverging definitions in separate directories (I wonder what maven does in that case…)?

There are monorepos. Some people / companies love them.

One of these companies we know for good. It is google. Google has one (!) repositoryf for all their software.

And that is the point I want to stretch here. One repo with one project and a standard source directory is too theoretical and too narrow in thoughts.

I think that you underestimate people when you say this.

Today there is no possibility to reliably make one product out of multiple repos. Git submodule and git subtree are not even close to something reliable and usable.

We are well aware of this. And that's why Pharo is not using any of them. But this goes against what you said before, or I'm not getting something.

Descriptions like metacello are language centric.

Yes. But I don't understand why this comes up. You would like language... "agnostic"? For example?

So what is the most secure way of defining a single product? It is the mono repo. That is the main reason I have my sources in backend/source because there is a javascript frontend in the same repo because I want to have one reliable source that defines my product and I can be sure that the backend and frontend are always the ones that match.

Just to repeat myself (and just to avoid missing it in the previous emails ^^). Can you describe better your needs for "multiple iceberg subdirectories"?

I don’t think it is a good idea if we once leave the island to embrace something like git just to make git islandish a little later.

I did not understand this...

Just to be very clear. We are talking about two files: .project and .properties. I have nothing against .properties because we have multiple formats possible so making it explicit is a good idea. But .project makes every repo a single source repo. If we enforce .properties files why do we not scan the repo for directories containing this file? If none is found we cannot know (or we add looking at some default locations). If multiple directory are found I can add that to iceberg as a real project out of the combination for repository-source directory.

This way I could have multiple projects out of one repo. And with the

possibility of having multiple source directories it is obvious that the path still needs to be added to a url in metacello.

Unless there is one of this directories marked to be the default which

would be loaded if no directory is given. This way the default directory would be the one selected if only one is there. So you can have multiple projects in one repo and if this is only one per project the directory can be automatically resolved. Use case kept.

Yes it could be done, but it's not so easy. I think you're underestimating the problem. For example, - tons of old projects have no .properties file. - so far iceberg only explicitly supported one code directory, and assumed that "no subdirectory" means root directory, not "default" one - If we discover two subdirectories in your repository, and you add a package into your repository, in which subdirectory should it be? - Should in this case be able to add the same package to both subdirectories? Do we commit them at the same time? Or they have different versions? Let's add that all these changes may involve changes in: - UI (and doing it properly takes time to design it, not just "coding" it) - merge Now, again, I can understand that the change make you uncomfortable, but I'd prefer that we talk about what are your needs instead of "how easy it could be done if we weren't stupid".

Norbert

On the other hand, separate source directories would be helpful to work with git-subrepo and similar tools… -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

-- 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 <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13