On a slightly related note - and I’m hearing what Norbert is saying as I need to work on multi language projects - it would be handy if I could specify the name of the project somehow.
My /exercism/pharo repo (which was created for me) - appear in Iceberg as Pharo - which is confusing, as I really want to call it Execercism, but have no way to do this currently (and I support its something the .projects file would enable right?) Tim > On 9 Aug 2018, at 11:17, Norbert Hartl <[email protected]> wrote: > > > >> Am 08.08.2018 um 14:12 schrieb Herbert Vojčík <[email protected] >> <mailto:[email protected]>>: >> >> >> >> Damien Pollet wrote on 8. 8. 2018 13:53: >>> First of all, quick stupid question: I'm currently loading my code with >>> gitlocal://./src <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 <[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>>> 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. > 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. Descriptions like metacello are language centric. 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. > > 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. > > 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. > > 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 >>> <http://people.untyped.org/damien.pollet>
