[Sugar-devel] Minor update to Make Your Own Sugar Activities!
Tony Anderson
tony_anderson at usa.net
Tue Mar 14 00:33:34 EDT 2017
Hi, Walter
On 03/14/2017 11:02 AM, Alex Perez wrote:
> ASLO is not a source code repository. It’s a convenience to end users.
> I know you think they should be one and the same, and in theory they
> could be, but I don’t necessarily see the benefit.
>>
The source code repository for a Sugar activity is the activity bundle.
ASLO is the source for Sugar activity bundles so it is, in that sense, a
source code repository.
I don’t see a reason why ASLO couldn’t simply be a front-end, pointing
to .xo activity files which are mirrored elsewhere (even HTTP-accessible
via Git/GitHub, or via a global CDN). That said, there is some value in
hosting the activities directly on ASLO. There is also some risk, since,
if ASLO goes offline, so does access to all activities.
I don't think anyone cares where the ASLO link goes. Actually, mirrors
of ASLO would be helpful.
However, a link to github is not a link to a bundle. It requires python
setup.py dist_xo to create a bundle from github.
Now we have duplicate systems for developers: developer hub on ASLO and
gaining access to the Sugarlabs github site.
Git can absolutely be used locally (with branches, tags, etc) without
external access to the Internet. It was designed to be use this way.
That said, I don’t see why Git needs to be a sugar activity. It just
needs to be a dependency of the development-specific Sugar packages
(RPM/deb/etc)
I assume by development specific you mean release specific.
i don't see a problem with git being a 'gnome' application in a sugar
installation. Essentially, the developer needs to make a commit of the
base activity which could be done with the directory in
/home/olpc/Activities (in Ubuntu, the activity may be in
/usr/share/sugar/activities; however, the user can copy to his own
/home/myname/Activities). This would enable reversion to the previous
commit in case a change breaks the activity.
If one wanted to update an activity, say TuxMath, now the first step
would be to clone the repository not install the activity itself.
This is an incorrect assumption.
This illustrates the problem. Yes, one can install the activity and does
not need to refer to the github repository. However, this assumes that
the version in ASLO is the currently released version. The Browse and
TuxMath activities on github are not available on ASLO, TuxMath is not
distributed with 0.110. So a developer who starts with the ASLO version
starts with one that is broken. I don't believe the ASLO version
activity.info links to the github repository. (It hasn't been updated
since 2010). Clone is probably the wrong word. I suspect the mechanism
is to download the zip file and then run setup.py locally.
Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20170314/ebf4fdab/attachment.html>
More information about the Sugar-devel
mailing list