-------- Original Message --------
The fact that it is done for some projects it does not mean it is
good. Moreover, it does not mean either that we can manage it well
:).
��- Just ask Stef the headaches he has every time he has to do a
change that crosses many packages�� and some of them are developed
outside the image (do we commit everything to the inbox, or do we
commit outside, wait for integration, integrate a configuration,
wait until everything is right, not break cyclic dependencies? and
so on...).
��- Or just see what happened with the metacello configurations of
the refactoring browser, opal, and so on.
Also, we are starting to see how to move Pharo sources to git, and
this means we are looking at how we should design Pharo's repository
so we can smoothly collaborate and synchronize repositories using
pull requests. For example, these two last week I took some hours to
evaluate and exercise myself with git subtrees and submodules.�� The
notes I made from this are here:
https://github.com/guillep/PharoIntegrationProcess/wiki/Analysis-of-sub-project-storage-alternatives
What I mean, adding a package inside the image can bring also a lot
of problems to package maintainers, so doing it just because "others
do it" is not a good argument.
What is an average user?
If you mean beginners, I can think of myself using a new language:
when I do not know how to do something in some new language, I
google for documentation or already done solutions (stack overflow
:P). Then I follow instructions if they are not too complicated. And
installing a library is inside my box for "not too complicated". I
do and did it all the time with maven, sbt, apt-get, npm, and it is
for sure not simpler than metacello most of the cases...
If you mean pharo users like you and me, I think then that using
Metacello should be a standard practice to manage projects and
dependencies.
Now, a nice step in the middle of both worlds would be making sure
that OS(Sub)process is in the catalog.