OSProcess is used for providing a quick way to link to VerveineJ in MooseImportFromVerveineJWizard. If we port this code to OSSubprocess, we can adopt it. Any takers?

Moose also depends on ZeroConf, which uses OSProcess through CommandShell.
Although this is quite confusing… ZeroConf depends on CommandShell but it loads just the ConfigurationOfCommandShell, not the package; instead it uses OSProcess directly (with specifying dependency on OSProcess).

If we can't have coexistence then we are introducing fragility into the system. As a user loading a package X you have no way of knowing if it will break unless you investigate the whole dependency tree.

So maybe both OSProcess and OSSubprocess should at the very least #preLoadDoIt: check whether the other is in the system and refuse to install, or ask the user for confirmation?



On Sat, Apr 30, 2016 at 6:33 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 30/04/2016 17:53, Peter Uhnák a écrit :


On Sat, Apr 30, 2016 at 5:14 PM, Thierry Goubier
 <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:

    Hi Peter,

    Le 29/04/2016 18:22, Peter Uhnák a écrit :

        Welp apparenty GitFileTree has already switched to OSSubprocess…
        which
        means that since I use Moose I can no longer commit my code…
        which is
        fun. -_-


    For Pharo 5.0, I've pushed both #dev and #stable versions of
    GitFileTree which will reuse either OSProcess or OSSubprocess if it
    is already loaded and will avoid reloading OSSubprocess over OSProcess.

    Could you try with Moose to see if it solves the problem you have?
    Just tell how it goes.


This indeed solves the Moose + Git problem, thanks!

It took me a lot longer to get all the Baselines/Configurations aligned properly (as well as testing and tuning the SmalltalkCI configuration) than writing/recovering the code.

Git makes child play of recovering a years' old version of a method :)

Although the underlying problem still remains… which I don't understand,
so I guess I will have to take a look to learn a bit.
Because imagine a year from now someone else comes along with a new
library, or OS(Sub)Process goes through a backwards-incompatible rewrite
into OS(Sub)Process2 and suddenly we are where we started...

 Well, there isn't much we can do about that.

Pharo and some of the underlying components change over time, and stuff needs to be maintained/adjusted to make the transition. Making APIs perfectly stable contradict the ability of Pharo to evolve.

Thierry

Peter



    Thierry

    _______________________________________________
    Moose-dev mailing list
     Moose-dev@list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch>
    https://www.list.inf.unibe.ch/listinfo/moose-dev




_______________________________________________
Moose-dev mailing list
Moose-dev@list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
Moose-dev@list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev