[IPython-dev] iptest on 0.11.alpha1.git

[Thomas Spura]

On Mon, 30 Aug 2010 13:11:27 +0200
Thomas Spura wrote:

> On Mon, 30 Aug 2010 00:32:20 -0700
> Fernando Perez wrote:
> 
> > On Sat, Aug 28, 2010 at 5:21 AM, Thomas Spura
> > <tomspur at fedoraproject.org> wrote:
> > > The commit hash will be noted in the version at the startup
> > > automatically after this commit:
> > > http://github.com/tomspur/ipython/commit/e2e56f2917d941051e99a893f3e26989b78aaa53
> > >
> > > And the branch name will be there after this commit:
> > > http://github.com/tomspur/ipython/commit/7b5f6ed4abd9308b9fc2a2071a756b0aba3a680b
> > >
> > 
> > Mmh, actually the more I think about this, the more reluctant I am
> > to have anything that opens a subprocess or imports a whole
> > repo-reading module just to get a version string.  Operations like
> > that have an impact on startup time, and IPython is arleady slow
> > enough to start up as it is.
> > 
> > We should think carefully about how to get that information in the
> > absolutely fastest, most static way possible in all cases.
> > Recording it in a file with post-commit hooks or something like the
> > old update-revno tool we had for bzr, but NOT with dynamic code run
> > at initialization time.
> 
> I rewrote the update-revno so that it does the right thing with git
> now: Replace branch name and revision number with the git-branch and
> git-revision. Unfortunately I didn't found yet a good git command to
> create an archive with the not yet commited changes...
> 
> > I really want our startup time to go down, not up.  A long time ago
> > I had a regular habit of starting up plain python and then ipython,
> > to compare the difference.   It used to be nearly undetectable, now
> > it's noticeable, and doing this kind of repo-spelunking at startup
> > time isn't going to help matters.
> 
> Hmm, yes, it would be great to have a good startup time, but that
> patch does is make worse when running in development mode. When
> releasing a version all that won't get even touched...
> 
> I could try to get the development startup time down too, but I think,
> it's not that important to think about maybe half a second more in
> development startup.
> It would be far better to set the release flag and compare that
> timing, isn't it?

This is now done with "./update_revnum.py" after this commit:
http://github.com/tomspur/ipython/commit/412b73175bb654f87653338bc3085c31ec7081db

Stays the problem with make-tarball: Currently it will make a tarball
of the latest commited changes, but not the changes made by
update_revnum... :(

	Thomas