[RFC] Pyrex .c file versioning

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> I want to add another point to the .c versioning discussion, which is
> that I think more and more distros are getting the ability to build and
> ship from VCS rather than tarballs: I think we *should* ship the .c
> files in a branch.
> 
> At a minimum this could be the 0.18 etc branch, but I think it would
> really be better to put them in bzr.dev.
> 
> I think the churn due to different pyrex versions is addressable:
>  - we can do a trivial script to change the paths
>  - we can nominate an official version we build with.
> 
> If we don't do this, I think its likely we will find distros that don't
> build the pyrex versions, or that encounter bugs related to having a
> different pyrex version in their build dependencies. Better for us to
> say 'heres the .c to build' consistently in all places we ship code.
> 
> -Rob
> 
> 

I still think there is too much churn when I'm committing in my own
branch. Since I run 0.9.5.1 on my Mac and 0.9.4.1 comes with Feisty.
Though I can say that 0.9.4.1 is actually slightly broken on Feisty
(with python 2.5).

I suppose I could manually install 0.9.5.1, but the point of using
Ubuntu was to not have to do my own package management.

Anyway, I know that we will explicitly run into churn with the path
names, and with the changes between pyrex versions. (The "built-in"
functions changed slightly between 0.9.4 and 0.9.5).

If you want to include them in release branches, I would be okay with
that. I haven't figured out a good way to create a release and make sure
they are included.

But we know that we would have to post-process the scripts for general
development (otherwise all the location paths would change), and if some
developers have 0.9.4 installed versus 0.9.5, then doing 'make' will change all
of the .c files (even with post processing).

I think requiring developers to use an exact version of Pyrex is a bit much,
especially since you still need to write a post-build script to remove all of
the absolute paths.

So, I'm +1 on having them in release branches, and -0.75 on having them in bzr.dev.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGiquQJdeBCYSNAAMRAqVZAJ9hfnK8p7q9pRKthHADZyVIK6ZgSgCfYsGx
xfcPgujBQ+mdYoNz7yivBJg=
=QsVj
-----END PGP SIGNATURE-----