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 overOSProcess.
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