On 26/11/2007, Ken Williams <[EMAIL PROTECTED]> wrote: > > > On Nov 25, 2007, at 9:20 PM, Adam Kennedy wrote: > > On 25/11/2007, Ken Williams <[EMAIL PROTECTED]> wrote: > > > > > > I agree that there needs to be some way of extending our notion of > > prereq types from the 2 current types (module and 'perl'). I > > disagree that it should be done in a backwards-incompatible way > > though. The cardinal rule of syntax extensions must be kept in mind: > > any new functionality must be a syntax/semantics error in the old > > system, or else old parsers will continue on their merry way and do > > The Wrong Thing. > > > I'd like to see some URIs that outline the logic behind this "cardinal > rule". > > > I thought this was common knowledge and obvious, but maybe I could find > some URIs. I'm just talking about the reason it's desirable e.g. for perl > 4 to fatally choke on "use File::Spec". >
That is quite a different thing. Once a certain piece of functionality is ALREADY incompatible with Perl 4, it is highly desirable to fail early and with a clear error, rather than wait for the actual point at which the error will occur (with a more obscure error). What you are suggesting is a NEW approach that has, as part of the design, the explicit intent to break compatibility. > I'm generally against any solution that starts with "first, break every > existing tool", and maintaining backwards compatibility wherever possible > has long been one of the principles by which the toolchain has been > developed. > > > Try to at least represent my point of view fairly, and then we'll talk. > There are several methods by which we might specify external dependencies. You prefer a method that breaks all existing tools everywhere (CPAN and darkpan) that look at META.yml to ensure they upgrade as well. I think that's a fair assessment of the situation. Am I wrong? My objection to this idea is similar to my main objection to Module::Build in the first place, namely that there was no way to cleanly upgrade to get the new functionality because of the circular dependency. It was proposed on the list that we make a backwards-incompatible change > from "requires => perl => $version" to "perl_requires => $version". I was > arguing against that change, and showing how we could move things forward > while entirely preserving backwards compatibility. > Breaking backwards-compatibility is always a judgement call between the benefits of the change vs the amount of pain you cause. In this case, we gain simplicity and clarity, and the cost is relatively minor since it is an unofficially and undocumented spec feature, and the number of places required to change is relatively minor (because it is a relatively new addition). Perhaps you really mean forwards compatibility but you think you mean > backwards. Are you worried about META.yml 1.2 parsers reading 1.4 specs, > or vice versa? Those are completely different issues from each other. > Probably. My preference is always for compatibility in both directions. If you want a guiding principle, then whatever change we make, the end user should never have to know it happened, everything should just continue to work. If we start breaking tools, that won't be the case. There will be inevitable situations we don't control in which people will only discover they are forced to upgrade after an hour trying to debug why their system has failed. > requires: > > mod/Carp: 1.03 > > mod/File::Basename: 2.73 > > sys/perl: 5.005 > > sys/platform: Windows > > bin/wget: 1.10 > > bin/gpg: 1.4.5 > > lib/tk: 8.4 > > lib/cups: 2 > > ext/mysql: 5.0 > > ext/openssl: 0.9.71 > > > This idea was originally proposed a couple of years ago. > > > I don't remember that. URIs? > The original discussions were between me an Audrey a couple of years ago, in relation to writing a META.yml lookalike for Perl 6, and probably aren't documented online anywhere. After the last YAPC::AU I spent some time with the author of the Mulgara RDF database. That meeting spawned the configure_requires: idea as the solution for the M:B circular dependency problem (and the EU:MM and M:I problems), and the idea of an inter-language RDF schema for this sort of information. You can see some of the back-of-the-envelope examples here. http://svn.ali.as/cpan/trunk/PIG/ I wrote a journal entry about it here http://use.perl.org/~Alias/journal/32221 Perhaps "proposed" is too strong a work, but there have been discussions on solving this external dependency problem, and it seemed that it wasn't going to be solved inside a Perl-specific context.
