see towards the end of the message, what I men with "block lists":
I mean some piece of (shared) machine readable source code listing the limitations, or rather the attribute. Like '(thread-safe yes) maybe even as part of the egg file (the license is already there, which would allow to filter for, say, "GPL compatible" or "GPL free"). It's a lot of work to figure all these things out of either source or documentation. The idea: maybe we can somehow share the results. Best Jörg Am Wed, 01 Dec 2021 21:23:21 +0100 schrieb Mario Domenech Goulart <ma...@parenteses.org>: > Hi Jörg and all, > > On Wed, 1 Dec 2021 10:30:44 +0100 "Jörg F. Wittenberger" > <joerg.wittenber...@softeyes.net> wrote: > > > one in a while I wonder how to handle a list of eggs not suitable > > for certain situations due to some undocumented internals. > > I think a first step would be removing the "un" prefix from > "undocumented". :-) > > > Examples like "egg used global variables" vs. "application uses egg > > from multiple threads" come to mind. > > > > Or the case with the "synch" egg, which, last time I checked, > > combined dynamic-wind and mutex use in a flawed way defeating the > > locking purpose.[1] > > > > So far I don't have a good idea how this could be dealt with. Guess > > some kind of configurable/selectable blocklist would be in order. > > After all global variables are OK if you know there is only one > > thread or you know about them and ensure proper locking. > > > > Important I'd find that the lists and reason of listing should be > > shared somehow. After all this is about learning undocumented > > things/facts/risks. > > Usually we have sections in egg documentation about assumptions, known > bugs, limitations, caveats etc. The documentation is in our wiki. > Everyone can make contributions to improve the quality of egg > documentation, including mentioning caveats. > > Ideally bugs should be fixed, of course. When they are discovered, > they should be at least reported (e.g., https://bugs.call-cc.org or > whatever issue tracker egg authors use). > > I'm not completely sure I understand what you mean by "block list". I > think the best we can do is document issues, really, and leave it up > to users to decide whether the issues are relevant for their use > cases or not. > > All the best. > Mario