[Question] Passing command line arguments to your flet application

[jnsh]

Question

Is there a way to pass command line arguments to your (built) flet application, for example to open a file indicated in the argument?

I can use sys.argv and if I run my flet code with python3 flet_code.py argument, I can parse the sys.argv[1] to get argument. However the arguments are not parsed on the built program. (Also I could not find a way to pass arguments if I run the code with flet run flet_code.py argument.)

Is there a supported way for command line arguments in flet, or is this something that is simply not possible for now?

Thank you in advance

Code sample

import flet as ft
import sys

def main(page: ft.Page):
    page.add(
        ft.SafeArea(
            ft.Container(
                ft.Text(sys.argv[1], size=50, data=0)
            ),
            expand=True,
        )
    )

ft.app(main)

Error message

No response

------------------------------------------------------

• I have searched for answers to my question both in the issues and in previous discussions.

[ap4499]

Check out this: #4252
and this: #4283

I think support for command line arguments was added in 0.25.(release).

I've put together a demo of this below:

import flet as ft

def main(page: ft.Page):
    page.title = "System Args Demo"
    
    # Display original system arguments
    args_text = ft.Text(f"System Arguments: {sys.argv}")
    page.add(args_text)

if __name__ == "__main__":
    import sys  
    ft.app(target=main)

That will then need to be build using Flet Build.

export PATH=$HOME/development/flutter/bin:$PATH
flet build macos --project "Demo" --product "Demo" --org "com.ABC" --company "Demo" --build-version "1.0.0"

Once it has been, an argument can be passed as follows (to the executable with the .app)
./Demo/contents/MacOS/Demo --arguments!

In the screenshot, we see the sys.arg that we passed in.

Does that help at all - or not what you were asking?

[jnsh]

Thank you for the response. And yes, this is exactly what I was looking for!

However, this does not seem to work for me. Using your code example, if I pass any command line arguments to the built program, the flet window opens, but only shows a white background and no text whatsoever:

If I run the program without any arguments, it will display "System Arguments: ['']":

I'm using Flet 0.27.6 on linux with python 3.12.5, and tested building against Flutter 3.27.4 and 3.29.1 with same results.

[ap4499]

I can't actually run 0.27.6 at the moment - I'm on 0.25 for production work (with Python 3.12.7/ Flutter 3.24.2) and there is a breaking change to upgrade to 0.27.6.

I have a feeling that this was dealt with in the Flet template (https://github.com/flet-dev/flet-app-templates).

I wonder if this is a regression, or, a Linux issue:

1. Does this work for anyone else not on Linux? Is this isolated to Linux?

Do you have any ideas @ndonkoHenri / @FeodorFitsner? Runnable code contained below.

To run this in a blank dir:

Shell commands:

rm -rf build
pip freeze > temp.txt
pip uninstall -r temp.txt -y 
pip install flet==0.27.6
export PATH=$HOME/development/flutter/bin:$PATH
flet build macos --project "Demo" --product "Demo" --org "com.ABC" --company "Demo" --build-version "1.0.0"
./build/macos/Demo.app/Contents/MacOS/Demo this_argument

main.py

import flet as ft

def main(page: ft.Page):
    page.title = "System Args Demo"
    
    # Display original system arguments
    args_text = ft.Text(f"System Arguments: {sys.argv}")
    page.add(args_text)

if __name__ == "__main__":
    import sys  
    ft.app(target=main)

[jnsh]

Unfortunately I can not test this issue on Linux with flet 0.25, since with that the built programs do not start at all (they simply hang and no window opens). This has been problem with any flet application, not only this example...

We are trying to get the build environment set up on MacOS though, to test whether this is occurring there with 0.27

[jnsh]

We were able to reproduce this on MacOS with Flet 0.27.6. Could not test Flet 0.25 though due to unrelated issues with the build. Either way it seems likely that this is regression after 0.25.

I opened bug report in #5128