run script in venv through Poetry

[hms5232]

I recommend running script through Poetry after Poetry is used.

Maybe consider migrate publish action to poetry-publish; test action can use actions-poetry?

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[afunTW]

Thanks for the recommendation. In my perspective, actions-poetry is the right way to prevent we invoke the tools outside the virtualenv.

However, we would not consider the publish action at this moment since this is a fork project and we are not ready for it.

[bluet]

As the original maintainer of the proxybroker is out of the grid, I'll publish the module under the name of proxybroker2 or something else in the near future once #82 💯

Thanks @hms5232 and @afunTW

[bluet]

@hms5232 Would you also like to help migrate to actions-poetry and poetry-publish?

[hms5232]

@hms5232 Would you also like to help migrate to actions-poetry and poetry-publish?

@bluet Yes, I will be willing to help this if project sure to migrate to Poetry 😄

[bluet]

@hms5232 Go Go Power Rangers!

[bluet]

@afunTW @hms5232 seems that we no longer need the requirements.txt, right?

[bluet]

@all-contributors add @hms5232 for code

[allcontributors]

@bluet

I've put up a pull request to add @hms5232! 🎉

[afunTW]

@bluet It depends on the project's orientation, here's the detail

1. If we aim to use Poetry as the only dependencies source, we don't need the requirements.txt but require to maintain the poetry.lock and pyproject.toml
2. If we aim to support multiple dependencies tools e.g. poetry, pipenv, pip etc, recommend keeping the requirement.txt and syncing all the states in all supported dependencies tools

[bluet]

@afunTW 1. seems to be easier to maintain. Any downside?

What do you suggest?

[afunTW]

@bluet
I would like to approach development-tools-agnostic and the maintenance could be solved by automation flow.

For example, the core developer and CI flow use poetry to maintain the dependencies, and CI flow generates the requirements.txt based on the lock file. It leads to anyone who does not familiar with poetry can still import the requirements.txt and contribute.

[hms5232]

@bluet It depends on the project's orientation, here's the detail

1. If we aim to use Poetry as the **only** dependencies source, we don't need the `requirements.txt` but require to maintain the `poetry.lock` and `pyproject.toml`

2. If we aim to support multiple dependencies tools e.g. `poetry`, `pipenv`, `pip` etc, recommend keeping the `requirement.txt` and syncing all the states in all supported dependencies tools

In my option, we don't need and have no time to fit every package manager which user used. If they prefer other tools or CI need something else, Poetry support that exports lock file to other formats. Just use poetry export and it will generate requirements.txt.

@afunTW 1. seems to be easier to maintain. Any downside?

What do you suggest?

In summary, I vote 1..

[hms5232]

Another point, Poetry is both a package manager and a virtual environment tool. Using Poetry not only make sure dependencies is same for everyone but also keep everybody's environment is clean.

[bluet]

@hms5232 @afunTW Hi I've opened a new issue for follow-up discussions #105