Experiment2

[bashtage]

• Closes #xxxx (Replace xxxx with the Github issue number)
• Tests added: Please use assert_type() to assert the type of any return value

[Dr-Irv]

In this case, it failed because changing pyproject.toml caused it to use a different cache.

So the issue now is that if we do update pyproject.toml, the cache is invalid and poetry figures out the dependencies again, and then something gets messed up.

[bashtage]

That is also my conclusion

[Dr-Irv]

That is also my conclusion

One thing to try is to use poetry use system before each poetry command (especially before poetry install) which I think will force everything to get installed into the "system" environment, and avoid having a virtual environment.

[twoertwein]

I think I tested disabling the poetry.lock caching but adding my local poetry.lock: it still failed (but maybe I'm misremembering something)

edit: tested it here dfba485

[Dr-Irv]

I think I tested disabling the poetry.lock caching but adding my local poetry.lock: it still failed (but maybe I'm misremembering something)

edit: tested it here dfba485

It's the other way that is not working. If the cache is invalid, then the CI is failing.

[twoertwein]

It's the other way that is not working. If the cache is invalid, then the CI is failing.

In theory, my local poetry.lock should be the same as the cached poetry.lock. When disabled caching and adding my poetry.lock, it should have the same effect - but it would always be a cache hit.

[bashtage]

Trying to skip the cache on windows.

[Dr-Irv]

Trying to skip the cache on windows.

I tried that last night. It doesn't solve the problem.

The issue here is that if there is no cache, it will fail. If we do get the cache, then it succeeds.

So we need to know that when we have a new version of pyproject.toml, which would affect poetry.lock, and then when we do poetry install, it determines dependencies, places all the packages in the virtual env, but then when we do any other poetry command, it is not using the virtual environment.

[twoertwein]

Is there a way to download the cached poetry.lock so that we can compare it to a newly generated one?

[bashtage]

If you know the location could just cat them.

…

On Thu, Sep 1, 2022, 20:51 Torsten Wörtwein ***@***.***> wrote: Is there a way to download the cached poetry.lock so that we can compare it to a newly generated one? — Reply to this email directly, view it on GitHub <#247 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKTSRMPCP7SYX44CVF25KDV4ECLFANCNFSM6AAAAAAQCLUQGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[twoertwein]

If you know the location could just cat them.

Would just need to do cat poetry.lock after loading the caching.

edit: well if the cache was still there - which is not the case on windows

[Dr-Irv]

Is there a way to download the cached poetry.lock so that we can compare it to a newly generated one?

I don't think that it matters. As soon as we update pyproject.toml, there will be no valid cached file, and we'll run into the current problem, because the CI will create a new poetry.lock file.

Also, I think I read on the action for installing poetry that they discovered that caching doesn't work on Windows anyway

[bashtage]

Should carefully check if any of the deps have changed from when it last worked. Could be something else, like virtualenv.

…

On Thu, Sep 1, 2022, 20:57 Irv Lustig ***@***.***> wrote: Is there a way to download the cached poetry.lock so that we can compare it to a newly generated one? I don't think that it matters. As soon as we update pyproject.toml, there will be no valid cached file, and we'll run into the current problem, because the CI will create a new poetry.lock file. — Reply to this email directly, view it on GitHub <#247 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKTSRLO73F754RLLUBVRZ3V4EDBPANCNFSM6AAAAAAQCLUQGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[bashtage]

Pinning poethepoet to 0.16.0 (vs 0.16.1) fixes the problem.

[Dr-Irv]

Pinning poethepoet to 0.16.0 (vs 0.16.1) fixes the problem.

Oooh. That's good news. I will test in what I'm trying just to be sure.

[twoertwein]

It might be worth pinning all versions in pyproject.toml (and also the github action versions to their exact version). We will need to update them every now and then but we might be spared a few days of debugging :)

[bashtage]

Closing in favor of #249

[Dr-Irv]

Created nat-n/poethepoet#88