Add initial new library (that will serve as a "best practice").

[beraldoleal]

We could create a new small library that will serve as "best practice" example model for others. Library to be decided. Comment here if you have ideas.

[ana]

I've been thinking about this and sadly, I didn't get any idea for a new library.

[willianrampazzo]

I think the network utility is a good candidate.

[ana]

I think the network utility is a good candidate.

There was this idea of implementing a new library, so nobody would be using it and it'd allow us to experiment.

[willianrampazzo]

I think the network utility is a good candidate.

There was this idea of implementing a new library, so nobody would be using it and it'd allow us to experiment.

Ah, okay, got it. I have two suggestions in mind that may be useful for us:

• Here, RFC: Add avocado plugin to install custom python packages for tests avocado#3678, Satheesh proposed a plugin to install pip packages before a test runs. I mentioned the Requirements Resolver could handle this. Right now, we don't have a runner for pip. Based on other runners' implementations, we usually use an utility. Maybe using the pip module in the runner is possible, or creating a wrapper for the pip as a utility is another possibility.
• Another utility that would be useful is a podman/docker utility. Soon we will need to handle container images better. Having a utility available would be helpful to speed up the process.

[beraldoleal]

I think the network utility is a good candidate.

There was this idea of implementing a new library, so nobody would be using it and it'd allow us to experiment.

Ah, okay, got it. I have two suggestions in mind that may be useful for us:

* Here, [RFC: Add avocado plugin to install custom python packages for tests avocado#3678](https://github.com/avocado-framework/avocado/pull/3678), Satheesh proposed a plugin to install pip packages before a test runs. I mentioned the Requirements Resolver could handle this. Right now, we don't have a runner for pip. Based on other runners' implementations, we usually use an utility. Maybe using the pip module in the runner is possible, or creating a wrapper for the pip as a utility is another possibility.

It would be nice, however since PIP v10, all PIP's code has been moved to pip._internal to make it clear that programmatic use of PIP is not allowed. So I'm wondering about the reasoning here and what walls we would hit here by creating a library with subprocess calls.

* Another utility that would be useful is a podman/docker utility. Soon we will need to handle container images better. Having a utility available would be helpful to speed up the process.

I have created the podman library when working with the podman spawner. At the time I was thinking about creating this library directly to the new repo, but because of its important user (podman spawner) I decided to go with the current location. I don't see a problem migrating this utility library to this new repo, however due this reason I would not choose to be the first one.

[beraldoleal]

Since the idea is to keep the import namespace, another idea would be to start migrating some "small and with low usage" libraries. Maybe utils/aurl.py and utils/stacktrace.py.