Sharing common Robot Framework code

Tools
1

Hi Robot Framework Community,

I´m asking if anyone has knowledge about advanced and practicable ways of sharing robot code across multiple repos in a professional development environment.
So how can we get rid of copying *.resource files from one repo to another and trying to get them always up to date?
I´m thinking about do something like ‘pip install common-robot-code’ in a git repository, has anyone solved the problem with pip?

I am open to any ideas and happy to get some answers on this topic. :slight_smile:

Happy coding!

2

You can share resource files via python packages; Robot Framework User Guide

If the resource file path is absolute, it is used directly. Otherwise, the resource file is first searched relatively to the directory where the importing file is located. If the file is not found there, it is then searched from the directories in Python’s module search path. Searching resource files from the module search path makes it possible to bundle them into Python packages as package data and importing them like package/example.resource.

1 Like
3

I dont get your answer and dont know what is different than normal *.resource files. Or do you share this python packages with PIP installation?
My questions is more about the intershareability between commonly used functions and keywords over multiple repos!

4

You have a resource file, you package the resource for into python package that can be installed with pip so that you don’t have to copy the files to multipe repo’s and just maintain your requirements.txt or pyproject.toml to fetch that package.

1 Like
5

This repo might be of use to you:
GitHub - robinmackaij/robotframework-poetry-demo: A package to demonstrate how poetry can be used to distribute Robot Framework resources within an organization

2 Likes
6

Thank you very much!
How does the packaging format of Poetry look like (sdist / whl ?) and can you directly publish the package from your commandline to your PyPi or different tracker?

7

Does Poetry store the *.resource files in the real folder structure in your repo or are they stored in the (.venv) directory in the package?

8

You can find all the details on the poetry home site:
Poetry - Python dependency management and packaging made easy (python-poetry.org)

poetry build builds the usual sdist and wheel. There’s a CLI options to build either instead of both.

poetry publish publishes the latest build artifacts. The default tracker is pypi but different trackers are possible. There’s more CLI options here: Commands | Documentation | Poetry - Python dependency management and packaging made easy (python-poetry.org)

1 Like
9

The *.resource files are included in the distribution that you’re building. This means the folder structure of the package remains the same.

If you install the package locally (developer mode), a reference to the local repo package root is added to the active environment (hopefully a .venv :wink: ).

Note that this is no different from how pip handles things. In fact, poetry calls pip to do the actual package retrieval and installation.

2 Likes
10

So the main benefit of Poetry is that is a more comfortable wrapper of PIP?
One config file instead of multiple files, e.g.

11

It’s a bit more than that. It’s a replacement for a setup.py. It manages environments. It’s a replacement for twine. It has better dependency resolving. It has (much) better dependency locking. It supports multiple dependency groups within a single file. And there’s probably some things I forgot.

pip only manages a very small part of a Python project / workflow. poetry is a one-stop-shop for the entire workflow.

2 Likes