RFE: unvendor pydevd module or update it to latest version

[kloczek]

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

[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. @karthiknadig or @int19h may know more.

Transferring this to a discussion.

[kloczek]

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

[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.

[kloczek]

You can still use older unvendored pydevd module.

[karthiknadig]

@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 @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.

[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.

[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.

[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.