You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems as though github actions updated the version of poetry that is used to run tests. Specifically it has this output:
Validate installed packages against 'poetry.lock' file
Run poetry check --lock
Warning: [tool.poetry.name] is deprecated. Use [project.name] instead.
Warning: [tool.poetry.version] is set but 'version' is not in [project.dynamic]. If it is static use [project.version]. If it is dynamic, add 'version' to [project.dynamic].
If you want to set the version dynamically via `poetry build --local-version` or you are using a plugin, which sets the version dynamically, you should define the version in [tool.poetry] and add 'version' to [project.dynamic].
Warning: [tool.poetry.description] is deprecated. Use [project.description] instead.
Warning: [tool.poetry.readme] is set but 'readme' is not in [project.dynamic]. If it is static use [project.readme]. If it is dynamic, add 'readme' to [project.dynamic].
If you want to define multiple readmes, you should define them in [tool.poetry] and add 'readme' to [project.dynamic].
Warning: [tool.poetry.authors] is deprecated. Use [project.authors] instead.
Warning: [tool.poetry.maintainers] is deprecated. Use [project.maintainers] instead.
Warning: [tool.poetry.keywords] is deprecated. Use [project.keywords] instead.
Warning: [tool.poetry.classifiers] is set but 'classifiers' is not in [project.dynamic]. If it is static use [project.classifiers]. If it is dynamic, add 'classifiers' to [project.dynamic].
ATTENTION: Per default Poetry determines classifiers for supported Python versions and license automatically. If you define classifiers in [project], you disable the automatic enrichment. In other words, you have to define all classifiers manually. If you want to use Poetry's automatic enrichment of classifiers, you should define them in [tool.poetry] and add 'classifiers' to [project.dynamic].
Warning: [tool.poetry.repository] is deprecated. Use [project.urls] instead.
Warning: Defining console scripts in [tool.poetry.scripts] is deprecated. Use [project.scripts] instead. ([tool.poetry.scripts] should only be used for scripts of type 'file').
Error: Process completed with exit code 1.
Most of these are indicated as Warnings, but there is one "ATTENTION" and it returns an exit code of 1 which indicates a failure.
I think we can just update the configurations which seems somewhat straightforward. The main thing I worry about is if the deployment scripts for the EC2 instances or someplace else use a different version of poetry check --lock. Then it may be that the new version of config will then be incompatible and cause worse issues than a simple github action failure which is for our own internal use.
I suppose the solution is to upgrade to the latest version of poetry everywhere so we don't have config incompatibilities if it's being used in multiple places. If it's on the server, I guess this gets installed with puppet (or ansible)? I think maybe a server-level config of base libraries is where it gets set up on the server.
The text was updated successfully, but these errors were encountered:
It seems as though github actions updated the version of poetry that is used to run tests. Specifically it has this output:
Run
poetry check --lock
Most of these are indicated as Warnings, but there is one "ATTENTION" and it returns an exit code of 1 which indicates a failure.
I think we can just update the configurations which seems somewhat straightforward. The main thing I worry about is if the deployment scripts for the EC2 instances or someplace else use a different version of
poetry check --lock
. Then it may be that the new version of config will then be incompatible and cause worse issues than a simple github action failure which is for our own internal use.I suppose the solution is to upgrade to the latest version of poetry everywhere so we don't have config incompatibilities if it's being used in multiple places. If it's on the server, I guess this gets installed with puppet (or ansible)? I think maybe a server-level config of base libraries is where it gets set up on the server.
The text was updated successfully, but these errors were encountered: