Skip to content

Potential thread safety issue under certain environments: Incorrectly nested style tag found #3010

Closed

Description

@abn

In certain environments, specifically CI environments, this issue occurs randomly. It would seem that when using the new executor for installation the io being used is not thread safe and pastel fails attempting to pop the wrong stack.

  • Installing glob2 (0.6)

ValueError

Incorrectly nested style tag found.

  • Installing httpretty (0.9.7)

Activity

  1. added
    kind/bugSomething isn't working as expected
    status/triageThis issue needs to be triaged
    on Sep 30, 2020
  2. PetterS commented on Oct 5, 2020

    @PetterS
    Contributor

    There are also other issues with the parallel installation: see #2658.

  3. added a commit that references this issue on Oct 7, 2020
  4. machielg commented on Oct 15, 2020

    @machielg

    I also have this problem when doing poetry (1.1.2) install in gitlab. The workaround is to disable the new installer: poetry config experimental.new-installer false

    it seems to fail at a random point or sometimes not at all.

  5. PetterS commented on Oct 15, 2020

    @PetterS
    Contributor

    Yeah, this should be relatively easy to fix. Just wrap a lot of calls to self._io with a lock in the executor. Alteratively, make IO from clikit safe to call from multiple threads.

  6. self-assigned this
    on Oct 30, 2020
  7. vikigenius commented on Dec 12, 2020

    @vikigenius

    Yeah, I am also facing this issue on aws, when using the user-data script to install poetry packages

  8. PetterS commented on Dec 14, 2020

    @PetterS
    Contributor

    For automation or when reliability is needed, the new installer should definitely be disabled.

    We have a config file in the repo disabling it by default. If anyone wants to use it (e.g. when setting up a new env), they can do so manually.

  9. michalszelagsonos commented on Dec 17, 2020

    @michalszelagsonos

    I hit this couple times now, also in CI. If I keep running into this, I may disable new installer which is a bummer since it significantly speeds up the install in my project with 100+ dependencies.

  10. sdispater commented on Dec 18, 2020

    @sdispater
    Member

    @Michal-Szelag-Sonos Which Python version are you using when the error occurs?

  11. michalszelagsonos commented on Dec 18, 2020

    @michalszelagsonos

    @Michal-Szelag-Sonos Which Python version are you using when the error occurs?

    I am seeing this on 2.7

  12. PetterS commented on Dec 18, 2020

    @PetterS
    Contributor

    Should happen on any Python version since IO is not thread-safe. This particular issue is easy to fix in the executor, though. There are other concurrency issues that are more tricky.

  13. sdispater commented on Dec 18, 2020

    @sdispater
    Member

    @Michal-Szelag-Sonos Which Python version are you using when the error occurs?

    I am seeing this on 2.7

    Yes, from experience I only have seen this on Python 2.7 and not on other Python versions, I am not sure why. I don't know if it's a coincidence or not though.

    It may also be caused by the futures package used on Python 2.7.

    Note that every write in the Executor class occurs after having acquired a lock so even though the IO is not thread safe, everything should work as expected.

  14. michalszelagsonos commented on Dec 18, 2020

    @michalszelagsonos

    So, silly question, can I use python3 poetry to manage a python2.7 project, assuming I would install poetry using pip3? It seems that this should work but double checking. I could test the 2.7 vs 3.x assertion by using python3 env for my toolchain which manages python 2.7 project and give it a few days to bake in.

  15. 27 remaining items

  16. jeffwidman commented on Aug 8, 2022

    @jeffwidman

    Looks like there will also be a installer.parallel false option that can be used in place of installer.max-workers 1.

    However, neither is available with poetry < 1.2, (as I just discovered!) so AFAICT, experimental.new-installer false is the only viable workaround for now... plus once 1.2 drops, these workarounds shouldn't even be needed.

  17. github-actions commented on Mar 1, 2024

    @github-actions

    This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

  18. locked as resolved and limited conversation to collaborators on Mar 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

kind/bugSomething isn't working as expected

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions