On Sun, Feb 13, 2022 at 12:07:44PM +0100, Gregor Riepl wrote:
> > So the solution I'm currently in the process of trying is to copy the
> > version from the oldest supported Python version at Debian package
> > build time. We'll see how this goes
> >
> >> Perhaps they have a maintenance scrip
> So the solution I'm currently in the process of trying is to copy the
> version from the oldest supported Python version at Debian package
> build time. We'll see how this goes
>
>> Perhaps they have a maintenance script for updating the vendored
>> dependencies? You could use that to find
On Wed, Feb 09, 2022 at 07:39:40PM +0100, Gregor Riepl wrote:
> > I realise now that this "nice" solution won't work, as the standard
> > library code says:
> >
> > import socketserver
> >
> > so modifying sys.path will just change the value of
> > sys.modules["socketserver"]. However, the vendo
> I realise now that this "nice" solution won't work, as the standard
> library code says:
>
> import socketserver
>
> so modifying sys.path will just change the value of
> sys.modules["socketserver"]. However, the vendored code instead loads
> this module to sys.modules["_pydev_imps._pydev_Sock
On Mon, Feb 07, 2022 at 09:27:28PM +, Julian Gilbey wrote:
> [...]
>
> I thought I could address this issue by replacing the vendored copies
> of the library modules by symlinks to /usr/lib/python3.X/, but now
> I've hit another snag: some of these modules import other modules.
> For example:
Hi,
I'm working towards packaging pydevd (which is a recursive dependency
of Spyder via IPython), and it's a somewhat challenging package! I
have hit an issue and would appreciate some thoughts on how best to
handle it.
Background:
pydevd is a debugging package which can attach to running scrip
6 matches
Mail list logo
