Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Could not find a version that satisfies the requirement debugpy==1.6.8 #1345

Closed
huyhoang8398 opened this issue Aug 4, 2023 · 21 comments
Closed

Could not find a version that satisfies the requirement debugpy==1.6.8 #1345

huyhoang8398 opened this issue Aug 4, 2023 · 21 comments
Assignees
@AdamYoblick

Comments

@huyhoang8398
Copy link

Before creating a new issue, please check the FAQ to see if your question is answered there.

Environment data

  • OS and version: MacOS 11.7.6
  • Python version (& distribution if applicable, e.g. Anaconda): Python 3.10.4 using venv
  • Using Neovim ( Pip install)

Actual behavior

    Installing pip package debugpy@1.6.8…
    ERROR: Could not find a version that satisfies the requirement debugpy==1.6.8 (from versions: 1.0.0b1, 1.0.0b2, 1.0.0b3, 1.0.0b4, 1.0.0b5, 1.0.0b6, 1.0.0b7, 1.0.0b8, 1.0.0b9, 1.0.0b10, 1.0.0b11, 1.0.0b12, 1.0.0rc1, 1.0.0rc2, 1.0.0, 1.1.0, 1.2.0, 1.2.1, 1.3.0, 1.4.0, 1.4.1, 1.4.2, 1.4.2.post1, 1.4.3, 1.5.0, 1.5.1, 1.6.0, 1.6.1, 1.6.2, 1.6.3, 1.6.4, 1.6.5, 1.6.6, 1.6.7)
    ERROR: No matching distribution found for debugpy==1.6.8
    spawn: /Users/kn/.local/share/nvim/mason/packages/debugpy/venv/bin/python failed with exit code 1 and signal 0.

Expected behavior

Install successfully debuggpy

Steps to reproduce:

  1. pip install debugpy
@mecampbellsoup
Copy link

My guess is this is because 1.6.8 was (attempted) published to PyPI, which recognized the commit was the same as 1.6.7, and didn't publish anything...

Either that or the PyPI automation they were testing w/ the 1.6.8 release didn't work!

@ghost
Copy link

ghost commented Aug 5, 2023

I found a workaround that involves manually installing debugpy in a way that matches Mason's installation process: create the directory ~/.local/share/nvim/mason/packages/debugpy/venv, install a virtual environment in the venv directory, then install debugpy with that virtual environment's pip using ~/.local/share/nvim/mason/packages/debugpy/venv/bin/pip install debugpy.

In your particular case @huyhoang8398, I believe you would execute the following (if you haven't done so already):

mkdir /Users/kn/.local/share/nvim/mason/packages/debugpy/venv/ -p
python -m venv /Users/kn/.local/share/nvim/mason/packages/debugpy/venv
/Users/kn/.local/share/nvim/mason/packages/debugpy/venv/bin/pip install debugpy

After that, try opening up Neovim and doing :Mason to confirm that debugpy is installed.

Granted, I'm using a Linux distribution while it appears that you are on a Mac system, so I'm not 100% sure if these commands will work perfectly (especially in the case of mkdir -p, which is meant to create the directory and any "parents" that contain that directory). In that case though, you can just use whatever means or methods you have to create the directory, create a virtual environment in that directory, and use the pip from that virtual environment to install debugpy. Hopefully this works while we wait for the correct version to appear on PyPI.

@GiorgosXou
Copy link

GiorgosXou commented Aug 5, 2023 •
edited
Loading

@temporal7 I figured this too, but I'm now stuck with this error:

E5108: Error executing lua: /home/xou/.local/share/nvim/lazy/nvim-dap/lua/dap.lua:493: .../xou/.local/share/nvim/lazy/nvim-dap/lua/dap/session.lua:1319: adapter.command must not be empty. Got: {
  command = "",
  type = "executable"
}
stack traceback:
        [C]: in function 'trigger_run'
        /home/xou/.local/share/nvim/lazy/nvim-dap/lua/dap.lua:493: in function 'run'
        /home/xou/.local/share/nvim/lazy/nvim-dap/lua/dap.lua:406: in function 'cb'
        /home/xou/.local/share/nvim/lazy/nvim-dap/lua/dap/ui.lua:34: in function 'pick_if_many'
        /home/xou/.local/share/nvim/lazy/nvim-dap/lua/dap.lua:400: in function 'select_config_and_run'
        /home/xou/.local/share/nvim/lazy/nvim-dap/lua/dap.lua:871: in function 'continue'
        /home/xou/.config/nvim/lua/astronvim/mappings.lua:358: in function </home/xou/.config/nvim/lua/astronvim/mappings.lua:358>
Press ENTER or type command to continue

cross-reference to a post in AstroNvim's discord server

@saiwing-yeung
Copy link

This works for me:
:MasonInstall debugpy@1.6.7

@iceychris
Copy link

My Pipfile.lock (using pipenv) currently contains this:

"debugpy": {
    "hashes": [
        "sha256:05d1b288167ce3bfc8e1912ebed036207a27b9569ae4476f18287902501689c6",
        "sha256:1ca76d3ebb0e6368e107cf2e005e848d3c7705a5b513fdf65470a6f4e49a2de7",
        "sha256:1fe3baa28f5a14d8d2a60dded9ea088e27b33f1854ae9a0a1faa1ba03a8b7e47",
        "(more hashes...)"
    ],
    "markers": "python_version >= '3.7'",
    "version": "==1.6.8"
}

So It seems like for some short period of time (probably while invoking pipenv lock), the 1.6.8 release kinda was present on pypi... (?)

Trying to install 1.6.8 explicitly now fails:

$ pip3 uninstall -y debugpy && pip3 install debugpy==1.6.8
WARNING: Skipping debugpy as it is not installed.
ERROR: Could not find a version that satisfies the requirement debugpy==1.6.8 (from versions: 1.0.0b1, 1.0.0b2, 1.0.0b3, 1.0.0b4, 1.0.0b5, 1.0.0b6, 1.0.0b7, 1.0.0b8, 1.0.0b9, 1.0.0b10, 1.0.0b11, 1.0.0b12, 1.0.0rc1, 1.0.0rc2, 1.0.0, 1.1.0, 1.2.0, 1.2.1, 1.3.0, 1.4.0, 1.4.1, 1.4.2, 1.4.2.post1, 1.4.3, 1.5.0, 1.5.1, 1.6.0, 1.6.1, 1.6.2, 1.6.3, 1.6.4, 1.6.5, 1.6.6, 1.6.7)
ERROR: No matching distribution found for debugpy==1.6.8

So yea, I guess one workaround is pinning to 1.6.7.

@sailorbob134280
Copy link

This works for me: :MasonInstall debugpy@1.6.7

That worked for me too

@windowsrefund windowsrefund mentioned this issue Aug 6, 2023
Closed
2 tasks
@sshishov
Copy link

sshishov commented Aug 6, 2023 •
edited
Loading

We are having the same issue!

But at least we can track it back and understand what happened. The release 1.6.8 was actually published, and our dependabot integration created an MR to update the dependency (what we did)

Dependabot MR details

Bumps debugpy from 1.6.7 to 1.6.8.

Release notes

Sourced from debugpy's releases.

debugpy v1.6.8

This release is identical to 1.6.7. It uses the same commit.

The purpose of this release is to test the new automated release pipeline we've created to deploy to PyPi.

Commits

I guess it is very unprofessional to release something to public (for testing) and then just remove it. At least the release should be YANKED form PyPi (at least it will produce the visual explanation).

By now I agree that we should just move back to 1.6.7 (and if you have a pin, you should update it).

@samedii
Copy link

samedii commented Aug 7, 2023

Forced to pin the version because of this...

@sinwoobang
Copy link

Same here. One of the granted contributors might need to take action.

@kiblik
Copy link

kiblik commented Aug 7, 2023

@AdamYoblick, I noticed your comment for release v1.6.8

This release is identical to 1.6.7. It uses the same commit.
The purpose of this release is to test the new automated release pipeline we've created to deploy to PyPi.

For me, it looks like the pipeline does not work because there is no package in https://pypi.org/project/debugpy/#history named 1.6.8.

Can you check it, please?

@sylvainmouquet
Copy link

poetry allows to install the release 1.6.8 as the latest version available but the package is not present in pypi

@infinitewarp infinitewarp mentioned this issue Aug 7, 2023
Merged
@Maffooch Maffooch mentioned this issue Aug 7, 2023
Merged
@AdamYoblick
Copy link
Member

AdamYoblick commented Aug 7, 2023 via email

@AdamYoblick
Copy link
Member

Sorry again for all the problems everyone, I should have removed the 1.6.8 tag and release when we pulled it from pypi. My fault. I'm new to this product and python releases in general, so I'm still learning. Appreciate the information 😄

@AdamYoblick
Copy link
Member

AdamYoblick commented Aug 7, 2023 •
edited
Loading

v1.6.8 tag and release have been removed, v1.6.7 is the latest tag and release for now.

I still need to test the release pipeline with proper signing, so the test release will be something like 1.6.7.post1.

Going to close out this issue since the offending release has been removed.

@AdamYoblick AdamYoblick self-assigned this Aug 7, 2023
@AdamYoblick
Copy link
Member

AdamYoblick commented Aug 7, 2023 •
edited
Loading

We are having the same issue!

But at least we can track it back and understand what happened. The release 1.6.8 was actually published, and our dependabot integration created an MR to update the dependency (what we did)

Dependabot MR details
I guess it is very unprofessional to release something to public (for testing) and then just remove it. At least the release should be YANKED form PyPi (at least it will produce the visual explanation).

By now I agree that we should just move back to 1.6.7 (and if you have a pin, you should update it).

Yeah sorry about this. The release was yanked, but we decided to actually remove it because of the signing issue. Won't happen again 😄

To be clear, this wasn't to test a new release, this was to test the release process itself. We moved to a brand new release pipeline (part of which we do not own) and that pipeline is not able to release to test.pypi because of security concerns. So the only place I could test was pypi itself.

@AdamYoblick
Copy link
Member

I was also unaware that versioneer (or maybe the way we're using it), which is what debugpy uses for versioning, requires a github release with an associated github tag. AND if the commit is the same commit as the previous release, it causes all sorts of problems, which is silly imo. But now we know 🤷

@sshishov
Copy link

sshishov commented Aug 8, 2023

Thanks for the updates @AdamYoblick . The good think that the issue has been resolved and we are lerning from the mistakes and oversights. Sorry for my arrogant sentence with "in-bold" words... just was a little bit frustrated that pipeline start failing all of a sudden...

I was just always thinking that it would be enough to YANK the release from pypy that pip will not try to install it, but pinned dependencies it is getting a little bit more complex, after yanked release (I assume) we should release next patch release the same as 1.6.7 or with just some fake commit to update the SHA that users will not stuck in yanked release and their dependabot would update the package automatically.

But the is no great solution here anyways, the best is to notify users about broken release and ask them to pin old version meanwhile, create some issue to track the progress and people can just subscribe to the updates of that issue... everything is imho!

@janvonrickenbach janvonrickenbach mentioned this issue Aug 8, 2023
Merged
@AdamYoblick
Copy link
Member

1.6.7.post1 has been tagged, released, and available on pypi. The commit hash is different from the 1.6.7 release. Since we've now proven that the new release pipeline works, there won't be any more of these test releases. Thanks again for understanding, and sorry again for causing headache to anyone 😄

@isaac-hazy
Copy link

Is this really fully fixed? I'm still getting poetry trying to install 1.6.8 and then failing to find it. Workaround at the moment is to pin to <1.6.8 but that's not ideal.

@AdamYoblick
Copy link
Member

AdamYoblick commented Aug 9, 2023 via email

@karthiknadig
Copy link
Member

This can happen if the poetry lock file has a reference to 1.6.8 from when it was still out. As you can see here there is no reference to it if you query pypi: https://pypi.org/simple/debugpy/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@AdamYoblick AdamYoblick

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests