If bdist_msi is used on a package which has a non released version
(defined from StrictVersion), it refuses to build the package. The code
for the bdist_msi mentions that pre-release is not supported. Knowing
nothing about msi, I don't know what shall be done for it to work.

This issue is highly annoying.  The ultimate cause is the msi code using
the StrictVersion class to get the version number.  StrictVersion is
documented to be constrained to numerical dot separated versions, and
there doesn't appear to be a way of providing that.  My extension has a
human readable version and I'm happy to also provide a different mangled
version to keep this command working.  I suspect the strictversion
doesn't actually matter than much and is only used to identify an
identical version of the installer so there is no reason why it can't be
automatically derived from the human readable version.

The problem is that the version number goes into the MSI ProductVersion property, which MUST be numeric, or else Windows will refuse to install the package. So this is not just an arbitrary choice (at least not by bdist_msi).

I'm not sure how a strictly numeric version could be determined from the metadata for a prerelease.

Is there any workaround we can use in setup.py to set correct version for build_msi subcommand only?

Metadata can be automatically figured out using regexp matching like ^\d+(\.\d+){2,3}, but for explicit handling there should be should some callback or msi-specific version property in metadata. In the end it is pretty logical if binary distribution process can be configured using distribution specific (bdist_* specific) properties.

In the meanwhile here is the workaround:
{{{

from distutils.command.bdist_msi import bdist_msi

class bdist_msi_version_hack(bdist_msi):
    """ bdist_msi requires version to be in x.x.x format
        because it is embedded into MSI
    """
    def run(self):
        # strip suffix from version, i.e. from 11.0.0+r3443
        saved = self.distribution.metadata.version
        self.distribution.metadata.version = saved.split('+')[0]
        bdist_msi.run(self)
        saved_version = self.distribution.metadata.version

setup(
    ...
    cmdclass={'bdist_msi': bdist_msi_version_hack},
)
}}}

Wrong code. The last line in the bdist_msi_version_hack override should be:

  self.distribution.metadata.version = saved

The above workaround still doesn't isolate version modification to bdist_msi command, because bdist_msi is calling `build` and `install` targets before doing its own stuff.

Any ideas how to override version for MSI without copying while `bdist_msi` contents?

Definitely something to think about in distutils2.

s/while/whole/

Sorry.

All right. The ultimate solution:

{{{
# Imports for converting version to MSI format for bdist_msi
from distutils.command.bdist_msi import bdist_msi
import inspect
import types
 
...

class bdist_msi_patch_version(bdist_msi):
    """ MSI builder requires version to be in the x.x.x format """
    def run(self):
        def monkey_get_version(self):
            """ monkey patch replacement for metadata.get_version() that
                returns MSI compatible version string for bdist_msi
            """
            # get filename of the calling function
            if inspect.stack()[1][1].endswith('bdist_msi.py'):
                # strip revision from version (if any), e.g. 11.0.0-r31546
                return self.version.split('-')[0]
            else:
                return self.version

        # monkeypatching get_version() call for DistributionMetadata
        self.distribution.metadata.get_version = \
            types.MethodType(monkey_get_version, self.distribution.metadata)
        bdist_msi.run(self)


...
setup(
    ...
    cmdclass={'bdist_msi': bdist_msi_version_hack},
)
}}}

To keep this focused, we should first try to make a test and patch for the stdlib, then discuss a recipe to work around the bug in unfixed versions.

What for? IIUC, it won't be fixed in distutils anyway.

Well, this is the bug tracker for the stdlib.  We have first to define clearly what the bug is, then find how to fix it in packaging (the name of distutils2 merged into 3.3), then decide whether to backport it to distutils.  Half-tested recipes to work-around the bug on unpatched versions divert attention and are out of place.

Feel free to copy this report for a clear user story - http://twistedmatrix.com/trac/ticket/5024

The issue is that projects want to generate MSIs for pre- and post-release versions.  As Martin said, there is an MSI limitation here (that should be documented in distutils doc).

I see two issues with munging the version number:

1) Both Twisted 2.0+r42 and Twisted 2.0 generate twisted-2.0.msi (filename simplified for the discussion), which will surely be confusing for humans and programs.

2) Does the MSI system allow people to go from 2.0+r42 to 2.0 if each of them is in a file named twisted-2.0.msi?

As for 2): I believe that bdist_msi doesn't support upgrade installations currently, anyway. To support this, the UpgradeCode property would have to be specified. As it stands, multiple versions of the same PyPI package result in multiple separate installations (potentially overwriting each other's files).

It would be possible to automatically derive an UpgradeCode from the metadata, however, we would then still need to define what versions replace each other, and what versions can be installed side-by-side.

In any case, the name of the MSI file is irrelevant (AFAIK). They could be named the same or differently - what matters to Windows is the package code, the product code, and the upgrade code. The ProductVersion matters for the UI, and to determine whether something is an upgrade. See

http://msdn.microsoft.com/en-us/library/aa370859(v=vs.85).aspx

Distutils is now deprecated (see PEP 632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils.

If this issue does not relate to distutils, please remove the component and reopen it. If you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools