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

Confusing error message if list of file paths parameter provided to ImportRequest is of type <str> #155

Open
2 tasks done
konradkudziagranta opened this issue Nov 14, 2024 · 1 comment · May be fixed by #160
Open
2 tasks done
Labels
bug Something isn't working good first issue Easy to solve for newcomers

Comments

@konradkudziagranta
Copy link
Collaborator

konradkudziagranta commented Nov 14, 2024

🔍 Before submitting the issue

  • I have searched among the existing issues
  • I am using a Python virtual environment

🐞 Description of the bug

Providing a file path in form of pure to any ‘files’ (data_files, combined_files, attachment_files) parameter in import request, results in error: “ValueError: File paths in import are not unique.“

Request object is expecting a list of strings, but when just a single str is provided, it carries on iterating through the parameter treating each 'char' as a separate path.

Should we add a simple ‘if not list’ check and throw more meaningful error msg in such case?

📝 Steps to reproduce

prepare ExcelImportJobRequest where one of files parameter is a 'str' instead of ['str']`
and create a job with it

import_request = jobqueue.ExcelImportJobRequest(name = "name",
                                                description = "description",
                                                template_file = ".\\myTemplate.xls",
                                                data_files = ".\\myDataFIle.xls") 


import_job = api_client.create_job_and_wait(job_request=import_request)

💻 Which operating system are you using?

Windows

📀 Which ANSYS version are you using?

ansys-grantami-jobqueue 1.1.0rc0
ansys-grantami-serverapi-openapi 4.0.0
ansys-openapi-common 2.2.0
GRANTA_MIScriptingToolkit 4.1.75

MI b. 25.1.1888

🐍 Which Python version are you using?

3.13

📦 Installed packages

ansys-grantami-jobqueue==1.1.0rc0
ansys-grantami-recordlists==1.3.0rc0
ansys-grantami-serverapi-openapi==4.0.0
ansys-openapi-common==2.2.0
certifi==2024.8.30
cffi==1.17.1
charset-normalizer==3.4.0
cryptography==43.0.3
filetype==1.2.0
GRANTA_MIScriptingToolkit @ file:///C:/Automation/STK/scripting-toolkit-4-1-75/pip/granta_miscriptingtoolkit-4.1.75-cp38-abi3-win_amd64.whl#sha256=7be8c6e46f63c29c0fde2a30911b2c3a607c5fb6443258b56e77339ca4db58b0
idna==3.10
jaraco.classes==3.4.0
jaraco.context==6.0.1
jaraco.functools==4.1.0
keyring==25.5.0
more-itertools==10.5.0
packaging==24.2
pycparser==2.22
pyparsing==3.2.0
pypiwin32==223
pyspnego==0.11.2
python-dateutil==2.9.0.post0
pywin32==308
pywin32-ctypes==0.2.3
requests==2.32.3
requests-negotiate-sspi==0.5.2
requests_ntlm==1.3.0
six==1.16.0
sspilib==0.2.0
urllib3==2.2.3
@konradkudziagranta konradkudziagranta added the bug Something isn't working label Nov 14, 2024
@konradkudziagranta konradkudziagranta changed the title Confusing error message if files path parameter provided to ImportRequest is of <str> type Confusing error message if list of file paths parameter provided to ImportRequest is of type <str> Nov 14, 2024
@Andy-Grigg
Copy link
Collaborator

I'd normally say that we shouldn't add this. The package is type hinted, which means a modern IDE will warn that you've done something wrong, and mypy will also throw an error if you provide a string when it expects a list. Also, the argument name is plural, which gives another very strong hint that some kind of container is expected.

This is a bit of a weird case in Python though, since strings and lists are both sequences, which can cause unexpected errors in cases like this. And since we don't actually try to resolve the file before raising the error, the error message is not obvious what's going on.

Should be fine to add this in.

@Andy-Grigg Andy-Grigg added the good first issue Easy to solve for newcomers label Nov 14, 2024
@Andy-Grigg Andy-Grigg linked a pull request Nov 15, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Easy to solve for newcomers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants