How to extract revision number to package/module version

Issue #19 new
anatoly techtonik
created an issue

It is very handy (esp. for development packages) to include revision number in package and module name.

Is there any common way to do this?

Comments (2)

  1. anatoly techtonik reporter

    I can't see any solution that helps me, so here is my use case. There is a project (`ctypesgen`, but that doesn't matter) that need to embed version and revision number for troubleshooting purposes inside its main module, and as a part of distribution name. This should be done when releasing package into the wild.

    This could be done with svn keyword substitution, but svn embed a last revision for a given file - not of the whole project. So there are should be some preprocessing before packaging.

    I expected Distutils2 to be the tool that designed to help automate building and packaging process, but the link you gave me tells that executable code and files are discouraged. That Distutils2 configuration should be static. There is some mention of post hooks, but no description where they should be defined and how to use them. I can't find any design document from Distutils2 planning, so it seems to me that one important part of analyzing user stories is missing here.

    In my user story there are three parts in delivering the package to end users.

    1. Preprocessing - embed revision number in source files (this should be dynamic)
    2. Packaging as either sdist or bdist (could be static config)
    3. Packaged sdist will lack version control directories, so its processing won't be the same as during build stage (could be static conf)

    So relating to extra code that is required to build distribution:

    1. Build code run when a source distribution is built
    2. Build code run when binary distribution is built
    3. No code run should be run when source distribution is installed
    4. No code run when binary distribution is installed

    One of the possible solutions it to ship only binary distributions, but:

    1. This doesn't work on Windows - it embeds machine-dependable paths
    2. I still want to ship non-compiled preprocessed source code, because there are no platform-dependent binary components

    So, there are two types of information that could be automatically processed:

    1. Packaging information used to build the package (revisions, packaging time, etc)
    2. Source setup to build the binary package (compiler keys, system-dependent settings, etc.)

    I couldn't find that Distutils2 separates packaging process in three phases, and packaging data in these two pieces, and without this separation it won't be better that previous Distutils from the point of package maintainers. Users will gain package query and uninstall tools, but for packagers it is still a headache. Maybe it is aimed to be changed in the future, but I couldn't find any formulated goals of Distutils2 project, nor the good solution for my user story. "new, improved version" is a very strange goal. Neither 5-page long post "Origin of the project" is an answer on the project scope.

  2. Log in to comment