RFE: unvendor pydevd module or update it to latest version

[Tomasz Kłoczko (kloczek)]

Looks like pydevd is well maintained and has regilar new releases.
Is it any reason why this module is bundled in debugpy tree?

[Rich Chiodo (rchiodo)]

I believe the reason it's bundled is so we can ship debugpy with Visual Studio and VS code without having the user install any packages. Karthik Nadig (@karthiknadig) or Pavel Minaev (@int19h) may know more.

Transferring this to a discussion.

[Tomasz Kłoczko (kloczek)]

I see that pydevd windows .whl is present on pypi so IMO it would be good to consider unbundle that modules 🤔

[Karthik Nadig (karthiknadig)]

debugpy is used in cross platform scenarios, like volume mapping it into a container for cases like azure functions, AWS lambda, etc. We want to avoid triggering installation in those cases. In some cases we need to pack all platform variants into a single bundle. Additionally, we also need to build and ship the binaries that are used in pydevd to have right publisher to avoid OS malware detection for flagging those as malicious (see https://github.com/microsoft/debugpy/issues?q=is%3Aissue+malware+is%3Aclosed )

Lastly there is some deviation from pydevd, at least back when DAP (debug adapter protocol) support was not yet fully in pydevd. So, we had the variant of pydevd vendored so there would not be breakages due to changes in the pydevd package.

[Tomasz Kłoczko (kloczek)]

You can still use older unvendored pydevd module.

[Karthik Nadig (karthiknadig)]

Tomasz Kłoczko (@kloczek) It does not address all the problem I mentioned above. We cannot sign a binary if it wasn't built using a trusted c-runtime. Additionally, there are customizations to vendored pydevd that don't exist outside of the vendored code (from what I remember Pavel Minaev (@int19h) might know the state better). Lastly, debugpy is moving to use sys.monitoring which means that there is further deviation from pydevd going forward.

[Tomasz Kłoczko (kloczek)]

So it is not vendorisation but forking .. so why not clean that code? 🤔
What is in debugpy source tree is still with many legacy python 2.x parts.

You cannot as well sign any python script.

[Brett Cannon (brettcannon)]

So it is not vendorisation but forking .. so why not clean that code? 🤔

That's up to pydevd's maintainer who we used to employ as a contractor and thus worked on debugpy and knows of the various changes made to the copy we ship.

Regardless, there are no plans to pull out our internal copy.

[Pavel Minaev (int19h)]

I believe it was all upstreamed eventually. However, debugpy still reaches out into what is technically pydevd internals in some places (attach to process, and I think some stuff around settrace), so depending on arbitrary new versions of pydevd is still potentially dangerous.

However, it was not supposed to be a fork. It is supposed to be updated regularly from upstream.