Frank Dana

(Last update, I swear...) Relative imports are also not required. Same warning if `src/mypkg/__init__.py` contains: ```python from mypkg.mypkg import myfunc ```

The `src/mypkg` version fails if you've done a _non_-editable install, in which case coverage does indeed produce a "no-data-collected" error, because `src/mypkg` is no longer being imported by the test...

If you run the above with `PYTHONPATH=$(pwd)/src` prepended, then it succeeds. Getting coverage.py to work correctly in a multiprocessing environment is apparently a _very_ difficult thing. The coverage.py docs [have...

> The `src/mypkg` version fails if you've done a _non_-editable install, in which case coverage does indeed produce a "no-data-collected" error, because `src/mypkg` is no longer being imported by the...

@MichaIng The reason for removing the workaround and allowing the system Python installation to revert to being "Externally Managed" is the same reason the PyPA developers created the feature in...

Apologies, just seeing this for the first time. The port conjecture is likely; the way to overcome that would be to explicitly quote the ID string. (So, `pydot.Node('"file:///#command_line_tool"')` rather than...

Without knowing more about the context, I can't say where the behavior changed, but if Pydot 2.x was processing input differently it was probably doing it _wrong_ in ways that...

@lkk7 > Why didn't I think of that? Because then I wouldn't get the chance to sound Clever™!

> Without knowing more about the context, I can't say where the behavior changed, but if Pydot 2.x was processing input differently it was probably doing it _wrong_ in ways...

(Also, note that they will all — including 4.0.1.dev0 — screw up an `id:port:compass`-format endpoint unless it's properly quoted going in.) This is a bug: ```python >>> import pydot >>>...