On Sat, Feb 02, 2013 at 11:26:50PM +0000, Andrew Chadwick wrote: > I'd like to reorganize the Python code a bit by introducing a new > top-level namespace, "mypaint", for the bulk of the mypaint program > code: > > lib.* → mypaint.lib.* > gui.* → mypaint.gui.*
The namespace seems somewhat redundant to me. It may makes sense with relative imports or when installed. Anyway, no big deal, I think. What I don't understand is what the benefit would be of moving the .py files around, when you want to keep the same basic separation (lib/ and gui/). Creating a folder called "mypaint" inside the mypaint project seems silly. It's not that we have another project lying nearby that isn't mypaint. But my bigger concern is that it disrupts existing patches and experimental branches, making it probably much harder to quickly bring them up-to-date and test with the current code. It also makes it harder to investigate file history. Git can track moves, but you always have to be explicit about it, and suspicious about whether it has actually worked. So I would like to understand the benefits of moving the files around. > * I want to revisit the way we do dynamically loaded subwindow modules > in order to do this part of the UI in a more GTK3-friendly way. Okay, but does moving files around help with that? The way we create subwindows by filename seems a bit hacky to me now, to be honest. Maybe subwindows should be registered with some API call, instead of relying on the file name convention. > One thing that's come up before when doing this is the security/safety of > importing the modules based on a string name: this would allow simpler > whitelisting. What kind of security/safety are you talking about here? What is the problem that would be solved? > * It would be nice to extend our submodule loading code to support > plugins. Yes indeed. > Plugin code should be able to import classes or constants from a > specifically mypaintish namespace if needed. This could be solved just as easily with a file named "mypaint.py" somewhere, which is imported by plugins. This file could just "import lib, gui" (or even select more carefully what API is exposed where). But I suspect that most plugins would just do "from mypaint import *" then, because they mainly deal with mypaint API calls and probably don't want to repeat "mypaint.gui.something" on every second line. (Some Python people even argue that "from foo import *" is how a domain specific language is created ;-) > Would doing this break any branches out there? git can probably track > changes across simple moves, but if there's anything that only exists as a > patch this might break it. I don't think tracking of moves goes as far that patches will apply to the moved path instead of the old path. I think many of the feature branches that are lying around, even trivial ones, could no longer be rebased. But maybe merging would still work? Or maybe the illusion that anyone is ever going to revive and integrate them can finally be laid to rest :-) > If there are no objections, I'll try to get this merged later this week. I'm not exactly objecting, just asking you to consider twice before moving paths around. Okay with me if it helps to make things clearer. -- Martin Renold _______________________________________________ Mypaint-discuss mailing list [email protected] https://mail.gna.org/listinfo/mypaint-discuss
