On Wed, Nov 16, 2011 at 11:15:21PM -0800, Michael G Schwern wrote: > On 2011.11.16 5:58 PM, Father Chrysostomos via RT wrote:
> > I think these patches are safe, but given the recent thread about > > dual-lifing test.pl I'm not even sure whether I should apply it or not. > > (Nicholas Clark does seem to have some good points.) > > This patch is not affected by that discussion. [Agree. Will try to get back to that in a different message] > > I don't really want to get involved in the thread, but let me ask you > > one thing (and I'll let others [e.g., rjbs] respond to your response): > > Why not simply fork test.pl? That way you can strip out the > > miniperl-specific stuff and have an even more lightweight testing > > library. You could even pop it in a .pm file, add package foo and > > @EXPORT, and with little effort you have a shiny new Test::More::Lite > > module. > > 1) It's not really my goal to make it distributable as a CPAN module, > but as just something you copy. It continues to be my goal to reduce the amount of effort needed to support the core. Exposing more of the internals runs counter to this. > 2) Test::More would lose the benefit of improvements from p5p. > > 3) p5p would lose the benefit of improvements from Test::More. The core is using Test::More for pretty much every core-maintained test outside of t/ One of the things I've been working on slowly is trying to turn "pretty much" to "every", by removing each impediment in turn. p5p continues to benefit from Test::More, and certainly I'm grateful for your continued work on that. (I assume everyone else is) > 4) I already maintain enough test modules, thanks. [referred to below] On Tue, Nov 15, 2011 at 06:16:37PM -0800, Michael G Schwern wrote: > First thing to clarify, I don't really envision this being turned into a CPAN > module. That would be directly against its purpose. > > The primary purpose here is to separate and focus development and provide a > point for module authors to copy it into their project. But that's not the point of t/test.pl It's not meant as a lightweight general purpose testing system. It's intended to test miniperl and low level Perl features, without assuming that everything is actually working. That it turns out to be a lightweight test system is, well, convenient. Convenient for other people. > It probably will *not* be released to CPAN and it probably will *not* be API > stable. The needs of the core outweigh the needs of the few people that use > it. Totally agree about the "needs of the core". But not on the interpretation. The continued experience of "the core" is that a: for any part that anyone can access, someone starts to rely on it. b: because anyone can read the core's source, they can see non-accessible parts that would be useful. But these parts were *never* written with any consideration to whether they make a sane *public* API. Historically what has typically happened is that someone has sent in a patch to expose it, "that's cool" (as everyone thinks about how they too could use it) and it's applied, as a "nuclear reactor" in bikeshed terms. Which ends up with ever more parts of "the core" exposed, replied upon, and implicitly supported. Right now, t/test.pl is not installed by the core. So it's an internal implementation detail of testing. Anyone else who uses it copied it, and by act of copying it to install it they've taken an action that acknowledges that they're violating a form of public/private encapsulation. > On 2011.11.15 6:34 AM, Nicholas Clark wrote: > > Other than people writing test modules, who would find it useful? > > Test::More is about to become a lot more complicated internally, so anyone who > does things which Test::More might be using. > > In addition, .t files which run a bazillion tests would find it useful both > for speed and memory usage. I just recommended Buddy Burden use it for some > huge Data::Random tests. Abigail could use it for her enormous Regexp::Common > test suites. > > But that's not really what it's about. > > The library upon which 372 core tests rely is undocumented and untested. > Moving it into its own repo and tracker allows it to be tested and stable > without having to go through the p5p memorial bike shed. That's the entire bloody point. It's not *meant* to be assumed to be stable. It's an internal implementation detail of testing the core. It does what *we* need quite nicely. We're not looking for patches for it to make it into something else. The "p5p memorial bike shed" *is* a problem (both for bikesheds and nuclear reactors, and everything in between) but assuming that it's a problem *here* is based on the axiom that t/test.pl is something that *should* be externally visible. An axiom which I reject. > It's a lot easier to get people to work on a single file Perl library than it > is to get them to patch the Perl core. In its own project, I can hand a > newbie a URL like this and say "pick one of these and do it!" > https://github.com/schwern/test-more/issues?labels=Easy You seem to be creating the need for something which to my mind doesn't need to exist. Patching t/test.pl feels like makework, not need. > >> t/test.pl is very important to the Perl core tests, but it is largely > >> undocumented and untested. Going through the p5p process to patch it makes > >> working on it difficult and open to bike shedding. If it were dual-lived > >> it > >> could be worked on as its own thing with its own commits and tests. > > > > test.pl is a script, not a package. Our machinery for dealing with dual > > life things is really only set up to deal with modules. So doing this is not > > going to just drop in to what we have. > > It will exactly drop in to what we have. No it won't. You're completely missing the large amount of structural refactoring that is going into the core's build process to be able to rearrange the layout of the distribution so that (ideally) *every* dual life file is below dual/ and every external upstream file is below cpan/, with the same file layout as the CPAN distribution. We've got nearly all the modules out of lib. Florian has now got third party Pod files out of pod/ and back into their distributions. Next target are various scripts in utils/, which currently rely on custom handling for VMS. We're trying to get to the point whereby all dual life files are in dist/ and cpan/, and byte for byte identical to the contents of known-version tarballs from CPAN. Preferably automatable and verifiable. Having something which is "copy this file" is a special case. > Pulling it into its own repository doesn't mean it has to be turned into a > package and modularized and all that. It would probably become lib/test.pl > and you just copy that into t/test.pl. Which also completely kills the ability to make a single commit which changes some part of t/test.pl and 100% of the users of that part. As Father Chrysostomos notes, there's a bunch of miniperl and core testing specific code in t/test.pl. That's the part that doesn't belong anywhere else, and often gets changed at the same time as its end users. > >> By having a dedicated feed of issues and commits, careful attention could > >> be > >> paid to what code and features are going in. Close attention and > >> discussion > >> can happen about whether the code is simple enough and the features apt for > >> the needs of the core. > > > > Surely the needs of the core *are* better determined by the core developers, > > not some third party group? > > The groups would obviously overlap and we wouldn't be stingy with the commit > bits. git is a distributed version control system. We get (different) stick for *having* commit bits, instead of following the "git" model of everyone working in their own repository and project maintainers pulling from them as needed. > > Also, having upstream be anywhere other than the core actively gets in the > > way of t/test.pl actually being useful to core developers (or at least to > > me, as a core developer who has added things to it). > > We deal with dual life files all the time, the same procedure applies. Yes. It *still* gets in the way. There are both benefits and costs to external upstream. > If you do it a lot (and you have this year) get a commit bit. Make the > changes in a sterile environment with tests. Copy it into blead. > > Or do it in blead and paste the commit ID into an issue on the project to get > someone else to pick it up. That's a lot more work than currently happens. > To put this in perspective, t/test.pl was edited just 28 times this year. > Nearly all of them were by you in March. Which surely means that I'm one of the key stakeholders here? And you're busy telling me that I'm doing it wrong. And that I need help on this. Neither of which I'm agreeing with. > > Even having it being upstream blead gets in the way of it being useful. > > Right now, as all users of the core's t/test.pl are in the core, it's > > possible to > > > > a: add things to it without stopping to think "is this a decent, supportable > > API that can last forever", because if the API turns out to be wrong, > > it's entirely possible to have a "flag day" commit that changes it and > > all its users > > b: remove things from it, because nothing is using them any more > > c: not worry about what versions of perl it supports, or working round > > problems in them > > (Although to be fair, if a particular piece of perl syntax had been > > buggy before, it's possibly something fragile that should be avoided in > > case it breaks again for a different reason) > > > > Nothing in the above stops anyone taking a copy of test.pl and using it. > > Doing this also doesn't add a layer of process into working on the core. > > I'm ok with all that. The goal is not API stability. Moving it to its own > repo does not prevent any of a, b or c. If it's not API stable, what use is it to anyone? They might as well take a copy from the core and keep using their copy. *That* will be API stable, and won't have anything they're using removed. > >> If folks are cool with that, I can set up a Github repository for it. > >> We'll > >> worry about whether CPAN release is appropriate later. > > > > I'm distinctly uncool about doing it that way. > > I'm unconvinced about doing it with blead upstream. > > I was thinking blead would be downstream. If someone wants to fork it into an external repository, that's fine. That's not going to be me, because just like you, I don't have time or desire to do this. A fork is fine. Dual lifing t/test.pl creates work trying to solve a problem that we don't have. Nicholas Clark
