As a comment to my use.perl journal post, Infinoid wrote: > Earlier today on the IRC channel, Will Coleda made an > interesting comment regarding partcl. > > 07:28 <@Coke> I'd rather have folks go to /partcl/ to get parrot. > > That makes a lot of sense. So, have you given much thought to how > you want to enforce and/or manage the version of Parrot you will be > running Rakudo under? I think this may be an important issue. > Given how much breakage we see in languages still in the parrot > repository, I worry that decoupling of parrot from rakudo will only > make the "moving target" problem worse. > > Presumably, Rakudo itself is in the best position to define which > version(s) of Parrot it expects to run under. So do you think > there should be some kind of startup sanity check? Or going even > farther, a "make parrot" target which (if the appropriate version > of parrot isn't found on the system) goes and fetches it, unpacks > and builds it?
Throughout the Parrot 1.0 planning process, I had been (somewhat forcefully) advocating that Parrot have its "make install" target working _prior_ to moving Rakudo out of the repository, and all of the Parrot milestone planning reflected that. Then Rakudo could simply say "install revision ##### of Parrot" and use that installed version to build and test Rakudo. Unfortunately it now looks as though repository moves are going to occur before Parrot's "make install" is working -- i.e., the reverse of what I had been advocating. That complicates things for us a bit. Parrot's plan is that language developers will target only "stable" releases (e.g., 1.0, 1.5, 2.0), but that's not likely to work for Rakudo. Indeed, given the way in which Rakudo currently drives Parrot feature development I suspect that even monthly Parrot releases aren't sufficiently frequent for Rakudo. (There are many times when implementing a Rakudo feature or fixing a bug necessitates adding or correcting something in Parrot, PGE, PCT, a core PMC, etc. Requiring Rakudo users to wait up to a month prior to seeing the benefit of that fix is not likely to work well in practice.) And, like you, I also have the concern about Parrot trunk changes breaking Rakudo, since it will be more difficult/less likely that Parrot developers will test their changes against Rakudo. So we probably don't want to track Parrot HEAD, but want to lag slightly behind -- recent enough to keep the most recent Parrot changes that we want/need, but not so recent that every Parrot commit has the potential to break Rakudo. My best guess at this point is to do something like you advocate-- i.e., have Rakudo build Parrot (whatever version Rakudo wants) instead of Parrot building Rakudo. We would then update the "required version" of Parrot as dictated by Rakudo timelines. In fact, for normal Rakudo users (i.e., people not also involved in Parrot development), we could just maintain a read-only copy of the "correct Parrot version" as part of the Rakudo repository. That would reduce the number of source code repositories that non-Parrot-committers would have to deal with for working with Rakudo. We wouldn't need Parrot's full revision history for this, or even all of Parrot. Thoughts? Pm
