[ASLO] ASLO build and deployment process (Jatin Dhankhar)

[Jatin Dhankhar]

Hi Tony,

I think the same, as per commit history project didn't get much attention
recently.

The website itself is implemented in PhP and is patterned after the Mozilla
> addons site.


Yes, the README mentions it's based upon Remora(
http://wiki.mozilla.org/Update:Remora ) which old and deprecated now in
favor of AMO (https://wiki.mozilla.org/AMO:Developers) .

At the moment I am trying to find out which of the activities actually work
> in the current release of Sugar. The library currently has about 600
> activities. A Sugar activity is intended to be self-contained (any
> dependencies not satisfied by Sugar are to be incorporated in the bundle).


I think it's a moonshot but I am thinking to include a testing suite to
determine whether a current version builds against a certain sugar version
by using a CI or something like  OpenSuse's QA (http://open.qa/) for more
comprehensive suite.

How this will be done is a mystery to me. Logically, each of the versions
> of an activity should be commited in git so that a developer (or
> maintainer) can the changes made over time.

Yes, that seems right thing to do, last year Arch Linux shifted all their
AUR packages to a git backend, maybe they can help, I can try finding
persons who carried out the transition.

If you look at the ASLO site, it seems clear that the page needs to specify
> more than which versions of Sugar are supported. It will need to specify
> which models of the XO are supported. It will also need to mention any
> restrictions on architecture or peripherals needed for the users system
> (microphone, camera, network connection - wired or wireless, and so on).


Yes more like a Manifest, similar to what Play Stores does for Android.

 My plan is to use Django (which enables code to be in Python and not PhP).
> The school server already provides sqllite, mariadb, and postgresql so db
> support is readily available. Django is designed to support fusion -
> creating web pages dynamically based on information from a db and so should
> match the requirement.

Yes, re-write seems a reasonable choice. One thing that I am curious is
that current repo suggests that it's is a mix of Python and PHP and going
full python would be a great move, in my opinion.


> Just for further background. Many deployments I work with have no access
> to the internet. To provide an alternative, I support a school server which
> XO users can access by wifi in the classroom

I think point makes a strong case for easily replicable instances of ASLO
with little to no configuration on the user side, which means we need to
make a simple and consistent build process so that users can run their own
versions of  ASLO easily. Docker is a option worth looking into.

I hope you will consider this challenging and not discouraging.

Yes, I find it equally challenging and interesting.

I made a proposal ASLO that shares some of the concerns that you discussed
. Kindly take a look and let me know what do you think of it. Here is the
proposal link
https://docs.google.com/document/d/1wECi_gtxyar3MWbC8ly6bjdW8SSLYe5YNcXPiTUUlkg/edit?usp=sharing


Thanks,
Jatin Dhankhar

On Sat, Apr 1, 2017 at 3:20 PM, Tony Anderson <tony_anderson at usa.net> wrote:

> Hi, Jatin
>
> The ASLO site is in desparate need of work. At the moment I am trying to
> find out which of the activities actually work in the current release of
> Sugar. The library currently has about 600 activities. A Sugar activity is
> intended to be self-contained (any dependencies not satisfied by Sugar are
> to be incorporated in the bundle). Naturally, an activity should work on
> any Sugar. However, this situation is becoming very complicated. First, two
> of the XO models (1 and 1.5) have Intel 32 bit architecture processors. The
> others (1.75 and 4) have Arm processors. Some of the activities incorporate
> binary modules which limit their use. The Sugar community wishes to support
> Sugar on a range of platforms. For mobile devices, Lionel Laske is
> developing Sugarizer. While traditional activities were implemented in
> Python (with some binary exceptions using Java or C), Sugarizer activities
> are written in Javascript (HTML5 and CSS). Naturally a trend in modern
> computers is to 64 bit architecture (AMD 64).
>
> The website itself is implemented in PhP and is patterned after the
> Mozilla addons site. It has a repository of activity bundles (.xo files)
> which is visible at http://download.sugarlabs.org. Each activity has an
> 'add-on' id (4000-4999 at the moment). Versions of activities are numbered
> beginning with 1 and incrementing by 1 with subsequent versions. So the
> directories in ASLO contain bundles for multiple bundles with the highest
> numbered version considered the latest. In addition to the bundle, the site
> contains metadata which is displayed in the pages devoted to an activity. I
> suspect this metadata is stored in a database but I haven't investigated to
> find out the details.
>
> In the meantime, Sugar Labs has decided to create a repository for
> activities in github. The reasoning appears to be that this will make it
> easier for the community to undertake ongoing development and maintenance
> of these activities. Currently, the ASLO site has a 'developer hub' which
> allows registered users to add or update their own activities. This
> function will need defined and moved to github.
>
> How this will be done is a mystery to me. Logically, each of the versions
> of an activity should be commited in git so that a developer (or
> maintainer) can the changes made over time. Also, some method is needed to
> manage over 600 additional repositories in the Sugar Labs github.
>
> If you look at the ASLO site, it seems clear that the page needs to
> specify more than which versions of Sugar are supported. It will need to
> specify which models of the XO are supported. It will also need to mention
> any restrictions on architecture or peripherals needed for the users system
> (microphone, camera, network connection - wired or wireless, and so on).
>
> Over time, Sugar has dropped many packages which were ordinarily included.
> This has rendered many of the activities currently unusable. For example,
> Sugar switched from a browser based on hulahop to one based on WebKit. Some
> effort will be needed to update activities using hulahop to use WebKit.
> Sugar Labs hopes that activities will be ported to GTK3 (called sugar3)
> from the original GTK (sugar). If this can be accomplished, the size and
> complexity of Sugar can be significantly reduced.
>
> I hope you will consider this challenging and not discouraging.
>
> Just for further background. Many deployments I work with have no access
> to the internet. To provide an alternative, I support a school server which
> XO users can access by wifi in the classroom. My hope is to provide a
> version of ASLO on the school server which will give these users the
> ability to install any of the activities they choose and for which their XO
> has storage capacity. That capability exists now (and has for some years).
> However, the selection is basically a list of activities by name and does
> not provide the metadata descriptions found on the ASLO pages. My plan is
> to use Django (which enables code to be in Python and not PhP). The school
> server already provides sqllite, mariadb, and postgresql so db support is
> readily available. Django is designed to support fusion - creating web
> pages dynamically based on information from a db and so should match the
> requirement.
>
> Tony
>
> On 04/01/2017 04:00 PM, Jatin Dhankhar wrote:
>
> Hi Tony,
>
> There are two major elements to Sugar. The desktop interface - Sugar and
>> the activities. ASLO is a library of these activities. Build only applies
>> to Sugar.
>>
>> For a non-XO version of Sugar, there are two easy choices: SOAS and Sugar
>> on Ubuntu. For Ubuntu, install 14.04 or more recent version (I am using
>> 16.04) and execute sudo apt-get install sucrose. For SOAS, download the
>> image and dd it to a usb stick. It works as a livecd.
>
>
> Thank you for all the information :)
>
> Make Your Own Sugar Activities!
>> By James Simmons
>> <http://www.lulu.com/shop/search.ep?contributorId=739770>
>>
>> Make sure to get the second edition.
>>
> Specially the book, it's very detailed and comprehensive.
>
> Another alternative is to build the 'development environment'. This
>> environment is intended for developers who are working directly on PRs for
>> Sugar modules.
>
>
> Yes, I am looking to build the 'development environment', specially the
> ASLO server but I am facing some issues. since sphinx is very old and
> cannot be compiled (using make) properly. Wanted to know if there is
> someone who maintains the ASLO and  can answer this specific query, related
> to building ASLO locally and getting started on it
>
> Thanks,
> Jatin Dhankhar
>
> On Sat, Apr 1, 2017 at 6:31 AM, Tony Anderson <tony_anderson at usa.net>
> wrote:
>
>> Hi Jatin,
>>
>> There are two major elements to Sugar. The desktop interface - Sugar and
>> the activities. ASLO is a library of these activities. Build only applies
>> to Sugar.
>>
>> For a non-XO version of Sugar, there are two easy choices: SOAS and Sugar
>> on Ubuntu. For Ubuntu, install 14.04 or more recent version (I am using
>> 16.04) and execute sudo apt-get install sucrose. For SOAS, download the
>> image and dd it to a usb stick. It works as a livecd.
>>
>> Another alternative is to build the 'development environment'. This
>> environment is intended for developers who are working directly on PRs for
>> Sugar modules.
>>
>> In deploying Sugar, the only fully supported platform is the XO. The
>> Ubuntu Sugar appears not to connect to networks and omits some of the
>> essential activities. These are the essential eight: Browse, Record,
>> Jukebox, Terminal, Log, Write, Read, and Image Viewer. Several of these
>> such as Record provide access to hardware features of the platform such as
>> the camera and microphone. Naturally, these are more difficult to support
>> on general platforms.
>>
>> There are two programming environments for Sugar activities: Python and
>> Javascript. HelloWorld and HelloWeb are simple examples of activities in
>> Python and Javascript, respectively. There is an excellent text available
>> for download online:
>>
>> Make Your Own Sugar Activities!
>> By James Simmons
>> <http://www.lulu.com/shop/search.ep?contributorId=739770>
>>
>> Make sure to get the second edition.
>> Tony
>>
>> On 04/01/2017 12:00 AM, aslo-request at lists.sugarlabs.org wrote:
>>
>> Send ASLO mailing list submissions to
>> 	aslo at lists.sugarlabs.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> 	http://lists.sugarlabs.org/listinfo/aslo
>> or, via email, send a message with subject or body 'help' to
>> 	aslo-request at lists.sugarlabs.org
>>
>> You can reach the person managing the list at
>> 	aslo-owner at lists.sugarlabs.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of ASLO digest..."
>>
>>
>> Today's Topics:
>>
>>    1. ASLO build and deployment process (Jatin Dhankhar)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Fri, 31 Mar 2017 16:57:58 +0530
>> From: Jatin Dhankhar <dhankhar.jatin at gmail.com> <dhankhar.jatin at gmail.com>
>> To: aslo at lists.sugarlabs.org
>> Subject: [ASLO] ASLO build and deployment process
>> Message-ID:
>> 	<CAD+LdAF26TWi9uPP0pPZPTFWm3L5HF3=ubc4_TBY9O8v_e=T1Q at mail.gmail.com> <CAD+LdAF26TWi9uPP0pPZPTFWm3L5HF3=ubc4_TBY9O8v_e=T1Q at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi,
>>
>> I have few questions about how ASLO is actually build and deployed in
>> production. Build process is carried out by using Fabfile, I tried using
>>  it and was not successful in building the sphinx ( since version used is
>> 0.9.9.rc2 and current series is 2.x).
>> Relevant pull request and issue
>> PR -> https://github.com/sugarlabs/aslo/pull/2
>> Issue -> https://github.com/sugarlabs/aslo/issues/1
>>
>> I am using Arch Linux and have installed all the necessary dependencies for
>> development including mysql and postgres development libraries along with
>> common development libraries. If anyone can point on how to successfully
>> build the project that would help a lot.
>> Some thread points out upgrading to new version of Sphinx but I wanted to
>> mirror the current instance.
>> Also project mentions something about Remorahttps://wiki.mozilla.org/Update:Remora and wiki says it's no longer
>> maintained.
>> It quotes
>>
>>
>> Remora is no longer maintained. See AMO:Developers<https://wiki.mozilla.org/AMO:Developers> <https://wiki.mozilla.org/AMO:Developers>.
>>
>> Also wanted to know more about how ASLO is deployed in production. What
>> techniques are used ? What are the pain points that need to be addressed
>> and tips on how to get started with it. If anyone is familiar with ASLO or
>> a long time maintainer, can they point out on how to reproduce a successful
>> build of ASLO (a documentation on how to run would be awesome)
>>
>> Thanks,
>> Jatin Dhankhar
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.sugarlabs.org/archive/aslo/attachments/20170331/12204ccc/attachment-0001.html> <http://lists.sugarlabs.org/archive/aslo/attachments/20170331/12204ccc/attachment-0001.html>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> ASLO mailing listASLO at lists.sugarlabs.orghttp://lists.sugarlabs.org/listinfo/aslo
>>
>>
>> ------------------------------
>>
>> End of ASLO Digest, Vol 84, Issue 1
>> ***********************************
>>
>> _______________________________________________ ASLO mailing list
>> ASLO at lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/aslo
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/aslo/attachments/20170401/c72eff0e/attachment-0001.html>