Re: [PATCH] Python scripts audited for minimum compatible version and checks added.

["Eric S. Raymond" <esr@thyrsus.com>]

Pete Wyckoff <pw@padd.com>:
> esr@thyrsus.com wrote on Thu, 20 Dec 2012 09:13 -0500:
> > diff --git a/git-p4.py b/git-p4.py
> > index 551aec9..ec060b4 100755
> > --- a/git-p4.py
> > +++ b/git-p4.py
> > @@ -12,6 +12,11 @@ import optparse, sys, os, marshal, subprocess, shelve
> >  import tempfile, getopt, os.path, time, platform
> >  import re, shutil
> >  
> > +if sys.hexversion < 0x02040000:
> > +    # The limiter is the subprocess module
> > +    sys.stderr.write("git-p4.py: requires Python 2.4 or later.")
> > +    sys.exit(1)
> > +
> >  verbose = False
> 
> If 2.3 does not have the subprocess module, this script will fail
> at the import, and not run your version test.

Yes, the import of subprocess should move to after the check.

> All the uses of sys.stderr.write() should probably include a
> newline.  Presumably you used write instead of print to avoid
> 2to3 differences.

That is correct.
 
> The name of this particular script, as users would type it, is
> "git p4"; no dash and no ".py".
> 
> Many of your changes have these three problems; I just picked on
> my favorite one.

Should I resubmit, or do you intend to fix these while merging?
 
> > diff --git a/git-remote-testgit.py b/git-remote-testgit.py
> > index 5f3ebd2..22d2eb6 100644
> > --- a/git-remote-testgit.py
> > +++ b/git-remote-testgit.py
> > @@ -31,6 +31,11 @@ from git_remote_helpers.git.exporter import GitExporter
> >  from git_remote_helpers.git.importer import GitImporter
> >  from git_remote_helpers.git.non_local import NonLocalGit
> >  
> > +if sys.hexversion < 0x01050200:
> > +    # os.makedirs() is the limiter
> > +    sys.stderr.write("git-remote-testgit.py: requires Python 1.5.2 or later.")
> > +    sys.exit(1)
> > +
> 
> This one, though, is a bit of a lie because git_remote_helpers
> needs 2.4, and you add that version enforcement in the library.

Agreed. The goal here was simply to have the depedencies of the individual
scripts be clearly documented, and establish a practice for future
submitters to emulate.

> I assume what you're trying to do here is to make the
> version-related failures more explicit, rather than have users
> parse an ImportError traceback, e.g.

See above.  At least half the point is making our dependencies
explicit rather than implicit, so we can make better policy
decisions.

> But what about the high-end of the version range?  I'm pretty
> sure most of these scripts will throw syntax errors on >= 3.0,
> how should we catch that before users see it?

That's a problem for another day, when 3.x is more widely deployed.
I'd be willing to run 2to3 on these scripts and check forward 
compatibility.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>