Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Feature Request: add a keyword to support reading a file from a module on the python path #5402

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.

Sign up for GitHub

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

Jump to bottom
Open
maddenj-ie opened this issue Apr 15, 2025 · 2 comments
Open

Feature Request: add a keyword to support reading a file from a module on the python path #5402

maddenj-ie opened this issue Apr 15, 2025 · 2 comments

Comments

@maddenj-ie
Copy link

To illustrate I'll describe my scenario.

I've created a custom Robotframework Resource module (packaged independently using Poetry etc. for distribution) which contains user keywords and resource files. Resource files not only refer to Robotframework Resource files, but any file required by the user keywords internal implementation.
I've followed the guidance provided on https://forum.robotframework.org/t/sharing-common-robot-framework-code/6977/1

In my example, the user keyword wraps an RPC style API where the contract is defined by an IDL file. The API uses binary serialisation and the IDL file is used to generate the codec for use internally.

My first naive approach used the standard Robotframework directory structure, cases, resources etc. The IDL file was referenced in the user keywords using a path relative to ${CURDIR}. This then failed when executed in a Robotframework execution environment which had the module installed.

To work around this, I added a Python utility to my Resource project, to read the file from a module on the Python Path.

        return importlib.resources.read_text(
            module_name, file_name, encoding=encoding, errors=errors
        )

Disclaimer: I'm a Python novice ;-)

This utility was then used in the user keyword.

This has the advantage of not relying on a search of the path that may result in a file with the same name being found elsewhere.

Conveniently, using the importlib, allowed support for different distribution, installation scenarios, e.g. downloads from pypi repo, install via *.tar.gz etc.

I've found #3317 but there's no progress on this yet.

Given the above, it may be useful to add a keyword similar to Get File from OperationSystem, to do the equivalent from a file in a module.

Thanks.
@pekkaklarck
Copy link
Member

Sounds reasonable. Do you @robinmackaij have opinions?

If we decide to add this, we have various ways to do that:

  1. Add a new keyword or keywords (there probably should be a separate keyword for binary files) to OperatingSystem.
  2. Add a module argument to the existing Get File and Get Binary File keywords.
  3. Enhance Get File and Get Binary Fileso that the path they accept can contain both module and path, for example, like module:path/file.txt.

The last approach would have a benefit that the same syntax could be used also with other keywords without introducing a new argument. It can be too magical, though, and it's also not totally safe because on Unix paths can contain : or any other such separator.

@robinmackaij
Copy link
Contributor

Seems like a good addition. I recognize the issue with shared keywords taking file names as arguments and then having to deal with relative paths within the module. That can be made to work by using the local ${CURDIR} but a cleaner / more flexible solution would be nice. Using importlib.resources would work for this.

My preference would be to go with option 2 since that'd prevent having very similar keywords (i.e. Get File and Get File From Module with the same signatures, except the module argument). I would say option 3 is on the "too magical" side and it not being natively safe doesn't help it's case.

Looking more broadly

Going through the methods available on importlib.resources also gives some interesting hooks for keywords to discover / show what's inside a "Robot Framework keywords distribution". Since these are not Libraries, a user has to know the package name but that's not enough; they also must know the names of the resource files made available by the package to be able to use them (including possible subfolder structures). Perhaps the importlib.resources methods can be used in the API / LSP for resource discovery of resources installed as Python packages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@pekkaklarck @maddenj-ie @robinmackaij