Skip to content

[Fix #438] Disallow empty project names #472

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

chandrikarj
Copy link

@chandrikarj chandrikarj commented Mar 2, 2025

Description

Fixes issue #438 : Disallow empty file name in TUI project setup

What is this PR

  • Bug fix
  • Addition of a new feature
  • Other

Why is this PR needed?

Currently, the TUI allows users to create a project with an empty name, which can lead to unexpected behavior.
This PR introduces a validation step to ensure that project names cannot be empty. If an empty name is detected, an error message is displayed, preventing project creation.

What does this PR do?

  1. Added a check in the project creation logic to verify if the name is empty.
  2. Updated the UI to display a clear error message when this occurs.

Demonstration of the changes:
https://github.com/user-attachments/assets/6b3fa0ec-e25b-4fae-a423-67d59b126062

References

Fix for issue #438

How has this PR been tested?

  1. Tried creating a project with a valid name → Works as expected.
  2. Tried creating a project with an empty name → Error is shown.

Does this PR require an update to the documentation?

Yes, minor update required to specify project name validation in the documentation.

Checklist:

  • The code has been tested locally
  • Tests have been added to cover all new functionality
  • The documentation has been updated to reflect any changes
  • The code has been formatted with pre-commit

"Project name cannot be empty. Please enter a valid name.",
severity="error",
)
print(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think instead of using a print statement, it would be more helpful to display this message in a dialog box. That way, users are immediately informed about the issue without needing to check logs.

Copy link
Author

@chandrikarj chandrikarj Mar 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @parharti, well your suggestion makes sense, and, the users don't need to check logs and can already see the statement in a dialog box. I had added the print statement to debug the same. Should you wish to, you can see it in the video linked under demonstration of the changes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

got your point!!

Copy link
Member

@JoeZiminski JoeZiminski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @chandrikarj thanks a lot for this! This implementation is working very nicely. I think however we can make this change further up the datashuttle call chain, and it will show the error both in the TUI and in the python API.

Under the hood, when the TUI is instantiated the python API is used. In code this would look like:

from datashuttle import DataShuttle

project = DataShuttle(")

This instantiates this class and sets the project name here.

If we place a check here, it will raise and error both in the python API and in the TUI for free. I just realized there is already a function here called _error_on_base_project_name to check the name does not contain special characters, but it misses the empty case. You could try adding the case here, and I think it will be caught in the python API and TUI.

Let me know if you have any questions!

"Project name cannot be empty. Please enter a valid name.",
severity="error",
)
print(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is okay to remove these print statements now, these are useful in development but if the error is already notified through the TUI these can be removed

@@ -422,6 +422,16 @@ def widget_configs_match_saved_configs(self):
cfg_kwargs = self.get_datashuttle_inputs_from_widgets()

project_name = self.interface.project.cfg.project_name
# Add validation before proceeding
if not project_name.strip():
self.notify(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! This is a cool textual feature, I think we could move towards using it one day. Currently we use modal dialog boxes to display errors, the class is here and called for example here. It achieves the same idea but is just more aligned with how the project currently displays errors for consistency. However, see my comment below I think we can get this for free with a change in a slightly different place in the codebase.

@@ -446,6 +456,17 @@ def setup_configs_for_a_new_project(self) -> None:
with the new project.
"""
project_name = self.query_one("#configs_name_input").value
# Add validation before proceeding
if not project_name.strip():
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just as a general tip, if you have a piece of code you are using in one place, you can create a function and place the code there, then call it from multiple places. The benefit of this is that if you need to change the code in future, you only have to do it in one place.

@chandrikarj
Copy link
Author

Thanks for your comments, working on this!

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 this pull request may close these issues.

3 participants