refactor(python): make mason optional during dap-python setup

[Sped0n]

📑 Description

• User might have a global debugpy installation, so we first check for debugpy-adapter before falling back to python
  • mfussenegger/nvim-dap-python@261ce64
• Only attempt to get debugpy package if Mason registry is available (since mason is optional and user might disable it)

ℹ Additional Information

N/A

[github-actions]

Review Checklist

Does this PR follow the [Contribution Guidelines](development guidelines)? Following is a partial checklist:

Proper conventional commit scoping:

• If you are adding a new plugin, the scope would be the name of the category it is being added into. ex. feat(utility): added noice.nvim plugin

• If you are modifying a pre-existing plugin or pack, the scope would be the name of the plugin folder. ex. fix(noice-nvim): fix LSP handler error

• Pull request title has the appropriate conventional commit type and scope where the scope is the name of the pre-existing directory in the project as described above

• README is properly formatted and uses fenced in links with <url> unless they are inside a [title](url)

• Entry returns a single plugin spec with the new plugin as the only top level spec (not applicable for recipes or packs).

• Proper usage of opts table rather than setting things up with the config function.

• Proper usage of specs table for all specs that are not dependencies of a given plugin (not applicable for recipes or packs).

[Uzaaft]

Took a quick look and something seems wrong/sketchy with this pr. I'll take a second look later.

[Sped0n]

Took a quick look and something seems wrong/sketchy with this pr. I'll take a second look later.

Perhaps explaining my setup will help you understand this PR.

Right now I’m running everything on nix, and all the binaries neovim needs (LSPs, formatters, etc.) are managed via nixpkgs, and I have disabled all mason related plugins in user.lua.

The debugpy‐adapter part might be a bit tricky, but I think calling require("mason-registry") is not okay since mason was already marked as optional (now every time I open a new py file, nvim pops up an error notification).

[Uzaaft]

That makes sense. Your implementation didnt imo.

Im too busy atm to take a second look so Im gonna let this be open for now.

[Uzaaft]

Went over this PR. This is what I noted down:

• Confusing fallback chain:
  First you check for debygpy-adapter, and then fall back to python. But then it appears that you potentially overwrite this with the Mason path, which seems to make the initial check pointless.
• Inconsistent path handling:
  The path variable seems to be used for different things. First the executable name, then a directory path, then a full path to a python executable in a venv.
• Unclear precedence: If both debugpy-adapter exists AND Mason has debugpy installed, which should take priority? The current code seems prefers Mason.
• Missing final path construction: When using Mason, it sets path to the venv Python, but dap-python likely needs the path to include -m
  debugpy.adapter.

The logic should probably be:

1. Check if Mason has debugpy installed → use it
2. Else check for system debugpy-adapter → use it
3. Else fall back to python -m debugpy.adapter

[Sped0n]

But then it appears that you potentially overwrite this with the Mason path, which seems to make the initial check pointless

it is intended, cuz i think mason users are majority and we should keep them unaffected from the change (always use the one from mason if user have it installed via mason), result is the same, but yeah your logic is way clearer

Missing final path construction: When using Mason, it sets path to the venv Python, but dap-python likely needs the path to include -m debugpy.adapter

it can take a path to

• python with debugpy installed
• or debugpy-adapter

so the old approach is fine, or you want to change it to append -m debugpy.adapter?

[Sped0n]

@Uzaaft, would you mind reviewing the latest force-pushed commit and let me know if it meets your requirements?

for me using a function with a early return seems to be the only way to escape from indentation hell, fell free to correct me if you have better idea on this

[mehalter]

@Sped0n I cleaned this up a bit and removed the necessity for the local function to save on computation time. Let me know if this works and I can go ahead and merge this!

[mehalter]

Actually I think we can clean this up quite a bit. Let me push another commit that should just clean this up completely

[mehalter]

Okay, this should be very clean and succinct now and not reliant on Mason, but will use it if it is available since Mason would install a debugpy-adapter executable to the path.

[Sped0n]

Okay, this should be very clean and succinct now and not reliant on Mason, but will use it if it is available since Mason would install a debugpy-adapter executable to the path.

yeah it works, thanks for the following up!