Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

product name ignored by flet build on windows #5062

Open
1 task done
asmaier opened this issue Mar 10, 2025 · 9 comments
Open
1 task done

product name ignored by flet build on windows #5062

asmaier opened this issue Mar 10, 2025 · 9 comments
Labels
documentation Improvements or additions to documentation packaging Related to app packaging

Comments

@asmaier
Copy link

asmaier commented Mar 10, 2025

Duplicate Check

Describe the bug

When building an app on windows, the name of the .exe file generated is not the name configured in pyproject.toml under

[tool.flet]
# project display name that is used as an app title on Android and iOS home screens,
# shown in window titles and about app dialogs on desktop.
product = "my-product"

Code sample

Code
[Paste your code here]

To reproduce

uv init flet_test --bare
cd flet_test
uv add flet[all] --dev
uv run flet create

Then edit pyproject.toml and change to

[tool.flet]
product = "my-product"

Finally run

uv run flet build windows

This will create .\build\windows\flet_test.exe instead of the expected .\build\windows\my-product.exe

Expected behavior

I expect flet build to use the variable tool.flet.product from pyproject.toml to name the generated executable file also on Windows. On Mac this actually works and

uv run flet build macos

will generate build/macos/my-product.app as expected.

Screenshots / Videos

Captures

[Upload media here]

Operating System

Windows

Operating system details

Windows 11 Pro 64Bit Arm

Flet version

0.27.5

Regression

No, it isn't

Suggestions

No response

Logs

Logs
[Paste your logs here]

Additional details

No response

@ndonkoHenri ndonkoHenri added bug Something isn't working packaging Related to app packaging labels Mar 10, 2025
@ndonkoHenri
Copy link
Contributor

ndonkoHenri commented Mar 11, 2025

What do you see in build/flutter/windows/runner/Runner.rc?

Image

@ndonkoHenri ndonkoHenri added the status: awaiting response Further information is requested label Mar 11, 2025
@asmaier
Copy link
Author

asmaier commented Mar 11, 2025

I see the following

BEGIN
  VALUE "CompanyName", "Flet" "\0"
  VALUE "FileDescription", "my-product" "\0"
  VALUE "FileVersion", VERSION_AS_STRING "\0"
  VALUE "InternalName", "flet_test" "\0"
  VALUE "LegalCopyright", "Copyright (C) 2025 by Flet" "\0"
  VALUE "OriginalFilename", "flet_test.exe" "\0"
  VALUE "ProductName", "my-product" "\0"
  VALUE "ProductVersion", VERSION_AS_STRING "\0"
END

@ndonkoHenri
Copy link
Contributor

ndonkoHenri commented Mar 11, 2025

  • project: project name for executable or bundle
  • product: project display name that is shown in window titles and about app dialogs

The project is the one used by Flet build as the name of the executable.

Can be defined in the following ways:

[tool.poetry]   # or [project]
name = "xyz"
  1. through the build command as --project xyz

It defaults to the name of you project directory.

Refs: windows, mac

@asmaier
Copy link
Author

asmaier commented Mar 12, 2025

  • project: project name for executable or bundle
  • product: project display name that is shown in window titles and about app dialogs

Interesting. So then it is working as expected on windows. But it is not working as expected on Mac OS. When I run uv run flet build macos I see

Packaged Python app ✅
           Found "icon" image at /Users/<user>/git/temp/flet_test/src/assets/icon.png
           Run subprocess: ['/Users/<user>flutter/3.27.4/bin/flutter', 'build', 'macos', '--no-version-check', '--suppress-analytics',
           '--build-name', '0.1.0']
[10:22:02]
[10:22:06] Building macOS application...
           --- xcodebuild: WARNING: Using the first of multiple matching destinations:
           { platform:macOS, arch:arm64, id:00006030-000C682802D0001C, name:My Mac }
           { platform:macOS, arch:x86_64, id:00006030-000C682802D0001C, name:My Mac }
[10:22:34] ✓ Built build/macos/Build/Products/Release/PRODUCT_NAME.app (136.0MB)
           Built macOS bundle ✅
           Copying build output from: /Users/<user>/git/temp/flet_test/build/flutter/build/macos/Build/Products/Release/PRODUCT_NAME.app
[10:22:42] Copied build to build/macos directory ✅

In my pyproject.toml I have

[project]
name = "project-name"
...
[tool.flet]
...
product = "PRODUCT_NAME"

So on MacOS it is the product name that is used to name the app, not the project name, despite what it says in the cookiecutter template.

@asmaier
Copy link
Author

asmaier commented Mar 12, 2025

Or even more clearer. If I run

uv run flet build --project PROJECT --product PRODUCT -v macos

I get

Building macOS application...
           --- xcodebuild: WARNING: Using the first of multiple matching destinations:
           { platform:macOS, arch:arm64, id:00006030-000C682802D0001C, name:My Mac }
           { platform:macOS, arch:x86_64, id:00006030-000C682802D0001C, name:My Mac }
[10:39:46] ✓ Built build/macos/Build/Products/Release/PRODUCT.app (136.0MB)
           Built macOS bundle ✅
           Copying build output from: /Users/<user>/git/temp/flet_test/build/flutter/build/macos/Build/Products/Release/PRODUCT.app
[10:39:53] Copied build to build/macos directory ✅

And actually If I try to run the same on windows

uv run flet build --project PROJECT --product PRODUCT -v windows

I get an error

CMake Error:
            Error evaluating generator expression:
[10:40:53]
              $<TARGET_FILE_DIR:flet_test>

            No target "flet_test"

On windows it seems the option --project doesn't work correctly and cannot overwrite the project name set in pyproject.toml. Only

uv run flet build --product PRODUCT -v windows

works as expected.

@ndonkoHenri
Copy link
Contributor

ndonkoHenri commented Mar 12, 2025

So on MacOS it is the product name that is used to name the app, not the project name, despite what it says in the cookiecutter template.

We will have a look.

On windows it seems the option --project doesn't work correctly and cannot overwrite the project name set in pyproject.toml.

Weird. Can you share the full logs with the erroneous command using --v?

@asmaier
Copy link
Author

asmaier commented Mar 12, 2025

Weird. Can you share the full logs with the erroneous command using --v?

Here it is:

flet_build_log.txt

@FeodorFitsner
Copy link
Contributor

"Product" name on Windows will be used in Task Bar, Task Manager, about window, executable manifest, etc. and it could(should) be something like "My Great App" (with spaces and other stuff).

@asmaier Do you want your Windows executable to be named as My Great App.exe too? I must admit it's uncommon for Windows and it should be my_great_app.exe.

@asmaier
Copy link
Author

asmaier commented Mar 13, 2025

"Product" name on Windows will be used in Task Bar, Task Manager, about window, executable manifest, etc. and it could(should) be something like "My Great App" (with spaces and other stuff).

@asmaier Do you want your Windows executable to be named as My Great App.exe too? I must admit it's uncommon for Windows and it should be my_great_app.exe.

No, I don't won't to have spaces in my exe name. But what I would like to have is a possibility to change the name of the .exe file (or .app file) without changing the name of the project in pyproject.toml. Because changing the name of a project has all kinds of side effects.
I would prefer to be able to set the option --project and --product for flet build also in pyproject.toml, e.g. like

[tool.flet]
project = "PROJECT_NAME".  # name for executable or bundle 
product = "PRODUCT NAME"   # display name that is shown in window titles and about app dialogs

Does that make sense?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation packaging Related to app packaging
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants