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

[ENH] - Option to set a custom name for an app #475

Open
pmeier opened this issue Sep 5, 2024 · 2 comments · May be fixed by #525
Open

[ENH] - Option to set a custom name for an app #475

pmeier opened this issue Sep 5, 2024 · 2 comments · May be fixed by #525

Comments

@pmeier
Copy link
Member

pmeier commented Sep 5, 2024

Feature description

Add an option to set a custom name for a deployed app instead of assigning it a random ID. If the name is already used by a different app, the form should display an error.

Value and/or benefit

  1. Apps that are deployed (semi-)permanently could have a human digestible and memorable URL.
  2. Apps that need to know the path prefix before they are deployed, e.g. FastAPI, can be deployed in a single step. Right now, the only way to do this is to deploy once, which will fail as expected. At that point the prefix is known and we can restart the app and supplying the prefix.

Anything else?

Talked with @aktech about this offline.

@aktech
Copy link
Member

aktech commented Nov 14, 2024

So, one way to tackle this in short term is to get rid of the random suffix and only add it when the name is taken, so:

1. first app

if the user name's their app as: Awesome Panel App
the url will be: awesome-panel-app

2. second app

If the user name's ANOTHER of their apps as: Awesome Panel App,
now the url will be something like: awesome-panel-app-d2598a as awesome-panel-app is taken by the first app

This approach makes the resulting url deterministic, without complicating the UI.

@pmeier
Copy link
Member Author

pmeier commented Nov 14, 2024

This approach makes the resulting url deterministic, without complicating the UI.

This approach makes the first resulting url deterministic, without complicating the UI.

This is good enough for the use case I have in mind, but shouldn't be more than a stop gap until proper UI error is being implemented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants