🔒 How To Achieve A Similar Result To The Windows '.exe' Installer By Building From Code in Windows

[frosty rampart]

I need to be able to:

1. Customize the location of the output folder for the build (Direct the build to a specific folder)
2. Create a build with the DLLs folder and its associated DLLs
3. Create an installation that has an identical file structure to the one created by the .exe installer.

When I build from code in Windows using the following steps:

1. Run 'PCbuild/build.bat'
2. Check PCBuild and amd64 folders
   I get a result like this: no DLL folder, cannot customize output folder, different file structure from the one created by the .exe installer [PCbuild_file.png, amd64_file.png, which are the images that show the folders PCBuild and amd64]

But when I use the Windows .exe installer, my result looks like this instead: has dll folder, can select output folder, and obviously different file structure from the one created by building from code [Normal_exe_build.png, which is the image that shows the Python310 folder]

How do I build from code such that I get exactly the same result as in the Windows installer? And if that is not possible, what tools do I need to use on the installation built from code to package it in exactly the same way that the build made by the Windows .exe installer is packaged?

[shy dove]

@frosty rampart

Python help channel opened

Remember to:

• Ask your Python question, not if you can ask or if there's an expert who can help.
• Show a code sample as text (rather than a screenshot) and the error message, if you've got one.
• Explain what you expect to happen and what actually happens.

:warning: Do not pip install anything that isn't related to your question, especially if asked to over DMs.

Closes after a period of inactivity, or when you send !close.

[desert cliff]

have you run PCBuild\amd64\python_d.exe?

[frosty rampart]

No, I haven't, I did try PCBuild\amd64\python.exe, will try your suggestion now.

[desert cliff]

uhhhh nvm

i read the instructions wrong

[frosty rampart]

Sorry, python_d.exe doesn't exist, it's because I ran the build without the debug flag.

[frosty rampart]

Oh, ok

[frosty rampart]

Basically, I'm trying to replicate what you can get by running the python .exe installer by building from source... I'm aware that the result is going to be different, but I also want to know what transformations/tools I must apply to get package the version built from source like the one built from the .exe installer.

[desert cliff]

sorry I am going to have to defer to the experts, I am not familiar enough in building python to be teaching anything

[frosty rampart]

No worries

[void hill]

So, you're trying to build an installer like the ones downloadable from python.org?

[frosty rampart]

To be honest, you're likely not going to need this, it's kind of niche and very specific to my situation.

[frosty rampart]

I mean, ideally I wouldn't need to? Just wondering if there were any tools (which I can't seem to find) or commands (which I might have missed out) to do so.

[void hill]

I think you need this script, then: https://github.com/python/cpython/blob/main/Tools/msi/buildrelease.bat#L4-L6

[shy dove]

Tools/msi/buildrelease.bat lines 4 to 6

rem This script is intended for building official releases of Python.
rem To use it to build alternative releases, you should clone this file
rem and modify the following three URIs.```

[crystal furnace]

you checked on venvs yet? it sounds like this could be what you lookin for?

[frosty rampart]

No, it's not.

[frosty rampart]

Venvs do not create the DLLs

[frosty rampart]

If I'm not mistaken, this will create the .exe installer, right? And the way you're suggesting I use this is to build with the same code, but rename the versions on my own, so that they have different version names, but are the same code behind the scenes anyways?

[void hill]

If you want to install the same python version as two different ones then with this approach you'd probably have the find where the installer's version is defined and change that.

[frosty rampart]

I see, and just to confirm, buildrelease.bat will output the the python installer executable, right?

I mean, I THINK that's what %BUILD% and OUTDIR do in the script.

[void hill]

I think yes, it by default should build two installers, for x64 and for x86. Weirdly, I can't find what step, if any, rearranges DLLs into a dedicated folder. There's only a few mentions of "DLLs" in the sourcecode, such as https://github.com/python/cpython/blob/3663b2ad54c9e15775a605facf69da8f5ee8d335/PCbuild/pythoncore.vcxproj#L128 - so maybe it's done on the build step and I just don't get how it works

[shy dove]

PCbuild/pythoncore.vcxproj line 128

PLATLIBDIR="DLLs";```

[void hill]

(Why do you need this, by the way?)

[void hill]

There's also a section about the installer in the tools readme: https://github.com/python/cpython/blob/3663b2ad54c9e15775a605facf69da8f5ee8d335/Tools/msi/README.txt#L61

[shy dove]

Tools/msi/README.txt line 61

Building the Installer```

[void hill]

This part may be what you're looking for: https://github.com/python/cpython/blob/3663b2ad54c9e15775a605facf69da8f5ee8d335/Tools/msi/README.txt#L135-L141

[shy dove]

Tools/msi/README.txt lines 135 to 141

To manually build layouts of the installer, build one of the projects in
the bundle folder.

    msbuild bundle\snapshot.wixproj
    msbuild bundle\releaseweb.wixproj
    msbuild bundle\releaselocal.wixproj
    msbuild bundle\full.wixproj```

[frosty rampart]

2 things, mainly:

1. Just a sense of satisfaction knowing I can actually build from source
2. I actually need a full python installation with the DLLs to interface with another application that I didn't develop, but that I must use. I'm not allowed to modify it (work stuff), and that application will stop working/freeze if it doesn't see the DLLs and a full python installation.

I mean, ONE workaround I had heard was copying over the python installation and rebuilding pip separately, but it felt ersatz and shoddy - and I was worried something would go wrong.

[void hill]

Possibly you may be interested in uv python. It downloads binaries from this project, and it looks like those have the right package structure (with a DLLs folder, etc) - so if you don't like the official installers, you could use these either via uv or just manually.

[frosty rampart]

Oooh, okay, let me try that then.

[wild igloo]

either the above python-build-standalone project that uv uses which are prebuilt python distributions or maybe the pyenv-win project https://github.com/pyenv-win/pyenv-win where you build it yourself with one command that you can set parameters for to change how the build is done and where it ends up might satisfy your requirements

[frosty rampart]

Uhh... I thought pyenv-win is meant for managing different versions of python?

[wild igloo]

that is one (and probably the main intended) use for it, but you can use it to build python and control how it is built and where it ends up as well

[frosty rampart]

I see, so can you build the same 2 versions of python with slightly different names?

And will those versions both have DLLs?

[wild igloo]

using the prebuilt distribution is the fastest and easiest if it fulfill your requirements as you don't need to wait for the compilation and you don't need to have all the prerequisites for building python installed on your system

[frosty rampart]

I tried, it will always recognize that I have the same version installed on my system... that is what I don't want...

[wild igloo]

they should all include DLLs as far as i know, i'm primary on linux and use the normal pyenv project which will build .so files which for dynamic linking on linux systems mostly like .dll files are on windows
i also use uv with their python-build-standalone distributions for a lot of stuff, but that is besides the point here

[wild igloo]

do you need them both to be available globally in the system?

[frosty rampart]

Not sure what you mean by 'globally', but if you mean 'added to path', no, that's not necessary'. But I do need them both to be full installs (with DLLs) rather than lightweight ones like in venv

[wild igloo]

but really the same version?
a little bit like if you have both 3.13.7 and 3.13.7t (the experimental free-threaded version of python of the same version) installed at the same time?

[frosty rampart]

Yes, it HAS to be the same version.

Absolutely the same version.

[frosty rampart]

Cos I'm testing several pieces of software that must be run on the same version/installation of python, but must have different modules installed.

It'd be NICE to have, but it wouldn't make work impossible if I didn't have it. But still, the need to know remains

[wild igloo]

i don't really see why you can't use venvs for this and just share the same DLLs amongst the different venvs and thus have different modules installed in the different venvs

[frosty rampart]

I tried it, the proram errored out.

[wild igloo]

in what way?
did you get any error message that you can share?

[shy dove]

Python help channel closed for inactivity

This help channel has been closed. Feel free to create a new post in #1035199133436354600. To maximize your chances of getting a response, check out this guide on asking good questions.