Ticket #2859 (closed enhancement: fixed)
view source should have copy to $HOME option
|Reported by:||walter||Owned by:|
|Priority:||Unspecified by Maintainer||Milestone:||Unspecified by Release Team|
View Source should provide an easy mechanism for copying the code to ~/ so that local changes can be made by the user. This would also involve some manipulation of sys.path to enable the user to run the modified code.
See discussion below:
[14:22] <rgs_> if this is a problem for Sugar (i.e.:, factoring some bits out as a python module) we would have to ponder another path
[14:22] <rgs_> Mokurai: you are either missing the file or hitting one of our paths are hard-coded limitations
[14:23] <rgs_> walterbender: could find some time to discuss with silbe/erikos this idea of factoring out core bits of TA as a Python module?
[14:23] <rgs_> walterbender: the major drawback i see is that you would need to be Root to install it
[14:23] <walterbender> rgs_: I think it already like that
[14:23] <Mokurai> The file isn't in the package. Was it supposed to be in a dependency?
[14:23] <rgs_> walterbender: unless we do something clever like
[14:24] <rgs_> walterbender: a) check TA is installed as a system module b) if not (old Sugar way) fallback to loading TA as a module by adding your current dir to the Python list of modules directory
[14:24] <rgs_> walterbender: i think that could be pretty clean and robust
[14:24] <mattva01> rgs_: I like that idea
[14:25] <Mokurai> rgs_: second the motion.
[14:25] <rgs_> walterbender: you mean already like that in the a) look for activities in /usr/something vs b) look in /home/foo/Activities ? Or in playing with Python's modules paths ?
[14:25] <rgs_> mattva01: Mokurai: cool, so we'll need to do some hacking before we are ready to ship packages
[14:25] <walterbender> rgs_: most of Suagr is installed in site-packages
[14:25] <walterbender> sugar and jarabe
[14:26] <rgs_> walterbender: well but kids don't usually update their Sugar stuff
[14:26] <rgs_> walterbender: how would we ship a turtleart-core update?
[14:26] <Mokurai> rgs_: Let me know which distros this will affect, so I can set up to test them.
[14:26] <walterbender> rgs_: good question
[14:27] <rgs_> walterbender: (unless we do the first look in your path and then try loading turtle art from the system)
[14:27] <walterbender> as long as we look locally first...
[14:27] <rgs_> walterbender: yeah
[14:27] <rgs_> walterbender: this dance might work
[14:27] <rgs_> try:
[14:27] <mattva01> rgs_: that works for me, though I need to get on all the mailing lists and dev stuff, i've been out of a loops a while, and was a student last time I worked on sugar stuff at all
[14:27] <rgs_> import turtleart
[14:27] <rgs_> rescue:
[14:27] <rgs_> sys.path += "."
[14:27] <rgs_> import turtleart
[14:28] <rgs_> walterbender: so when we generate a .xo we'll just keep doing the same thing
[14:28] <rgs_> walterbender: and when you try to run the gnome frontend import turtleart will just work
[14:28] <rgs_> cause it'll be installed in /usr/lib/python2.7/something/
[14:29] <rgs_> mattva01: no worries, this changes shouldn't be that big and will probably fixing some bugs that are out there. We just need to put some order in the way Turtle Art finds its components
[14:29] <walterbender> rgs_: I would rather do it the other way around... look in . first... then sys.path
[14:29] <Mokurai> rgs_: Presumably this will affect packaging for other activities.
[14:30] <rgs_> walterbender: right, optimize the Sugar case. Makes sense
[14:30] <walterbender> rgs_: I'd like all of Sugar to work that way... copy a component into . and then modify it... delete it and you are back to the installed version
[14:30] <Mokurai> walterbender: +1
[14:30] <walterbender> rgs_: so viewsource would have an option to do the copy
[14:31] <mattva01> that's actually a great way to get back to the original design goals of sugar, it makes it a lot easier to modify
[14:31] <walterbender> rgs_: seems the most straightforward way...
[14:32] <rgs_> walterbender: i like that