Possible bug in app start message

🎈 Using Streamlit
1

Hello,

I’m beginning to get familiar with streamlit, and I’m noticing a strange behaviour.

I’m running my app with the following command:

python -m streamlit run app.py --server.port <a_port_of_my_choice> -- arg1 arg2

Here, arg1, arg2 etc. are configurations etc. that my program use though sys.argv.

Irrespective of whatever port I use, be it 8501 or 8502 or 8503 or anything, the terminal shows this:

You can now view your Streamlit app in your browser.

URL: http://localhost:8501

But the app is actually available at the right port, i.e. the one I provided.

It does not seem to be an expected behaviour, but I’m really new to streamlit. So, can someone please confirm whether it’s a bug or not?

Also, unrelated to this (possible) bug report, I’d like this message to appear some time after the app starts. In my app, I’ve some initial calculations, not all of which can be cached. So, I’d want this message to be displayed after that is done, so that the user do not see an empty page at the start. Is that possible?

Thanks.

2

Welcome to the Streamlit community @Yarnabrina!

My guess is that your non-standard method of running Streamlit is causing the port argument to go through sys.argv, instead of into the streamlit executable.

Is there a specific behavior you are trying to achieve by running python -m streamlit run app.py --server.port <a_port_of_my_choice> -- arg1 arg2 instead of just streamlit run app.py --server.port?

Best,
Randy

3

Hi @randyzwitch, thanks for the nice welcome :slight_smile:

I’m not actually sure why do you say that my method to run is non-standard. My application needs a few other configurations to be passed.

To give some details, it’s a NLP app for topic modelling, and few configurations are for number of topics to consider, number of iterations of training, etc. I’ve created a configuration file and the path to that file is basically my arg1. For now, let’s ignore arg2 as that’s optional.

So, my plan was I’ll pass flags to streamlit itself by specifying before the empty --, and the configurations to my codebase after that. Is that not standard? Even streamlit docs suggest this, if you see the blue NOTE section.

I’ll be happy to do it some other way if you suggest.

(Edit)

To add to my point above, I was using double dash following this:

However, I found out later that even if I don’t pass it after --, for example the following command, my code is not receiving server.port.

python -m streamlit run app.py --server.port <a_port_of_my_choice> arg1 arg2

Inside my codes, sys.argv is ["app.py", "arg1", "arg2"]. I’m not sure how it happens though, as passing server.port after my arguments also lead to the same.

Anyway, even without --, i.e. using the command I shared above, the URL is still displayed incorrectly. Am I missing something very simple? :confused:

4

It’s a standard way of doing it for Python programs, but not for starting Streamlit apps.

This gets more to what makes it non-standard…usually, people would have these as widgets in the Streamlit app, so that you could run different configurations. After all, assuming that the app would published somewhere, any user besides you wouldn’t have access to pass arguments via the command line.

5

This is kind of by plan. The intended users of the app are non-technical, and I do not want to provide them options that make them confused. The objective of the app is for them to explore the result based on pre-trained model, trained before deployment possibly. At least, that’s the plan for now, may evolve in future.

Anyway, in my honest opinion, I think incorrect display of the link is a bug. If streamlit is intelligent enough to capture my passed port, and make the app available there, I’d expect it to show the correct URL as well. Or, at least it should not show an URL which is not correct.

6

In case any one is interested in this, I tried to debug this and narrowed down to the minimal change as far as I could. It was the presence of configuration file (.streamlit/config.toml).

I created a GitHub issue for it, and hopefully further updates will be available there. Closing this thread marking this as the solution.