[Sugar-devel] Mode of distribution of Sugar Activities

[Srevin Saju]

To all,

I will be releasing Sugarlabs appstore v0.1.alpha this weekend!

Please review repositories at https://github.com/sugarlabs-appstore

For an updated working example: https://sugarstore.netlify.app

================

Reply to previous email below, sorry for delay;


On 30/06/2020 10:38, James Cameron wrote:
> On Tue, Jun 30, 2020 at 09:50:45AM +0300, Srevin Saju wrote:
>>      Remember that in my design for aslov4, it must "support activity
>>      bundles uploaded via ssh,"
>>
>> I have seen and read the GSoC guidelines. I have also noticed that
>> aslov4 should support activities uploaded by ssh. But it is almost
>> impractical in my case. I do not own a ssh server so I cannot build
>> / deploy a server / storage where I could publicly give ssh access
>> to developers at sugarlabs. The best I could do is to make use of a
>> free service (in this case, GitHub; but I have also mentioned of the
>> alternatives to GitHub in my first email, (because personally I do
>> not prefer Github too). If in case, I get access to a free ssh
>> server on Google Cloud Platform or something, I will extend this
>> feature.  Because, I cannot implement a feature which I cannot test.
> You can SSH into your computer for testing.  Look for a way to add SSH
> server listening on localhost address, yet refuse on your external IP
> addresses.
>
> You can also SSH into a VM or chroot on your computer.
>
> We also have sunjammer.sugarlabs.org which provides SSH access for
> activity maintainers.  That's how the tarballs are provided in
> download.sugarlabs.org and some bundles in people.sugarlabs.org.

Thanks, I recently added the support to build from pre-built bundles. On 
#7 last 50 commits aims at making builds possible, but I still prefer 
building from source. But you may choose :D

>> But this is absolutely possible, because sugarappstore-generator
>> script is modular, I can easily provide the bundle location and it
>> can automaticaly generate the static location. In this case, a
>> custom `list_activities` needs to be defined to find uploaded
>> bundles.
> Good.  Are there instructions for how I can deploy this to sunjammer?

I have a small documentation on the README.md of the repository. Do let 
me know if, something is missing from the README that you would like to 
include.

Executing

python3 -m saasbuild --help

will give almost all the possible options. The best part is that most of 
the functionality is configurable either from environment variables or 
command line arguments / parameters.


>>      and may also "for a specific list of
>>      activities, access the source repository and detect any change to a
>>      release tag (publish), create a bundle and extract release notes,"
>>
>> I am not sure if you have noticed, I have added support for all
>> activities to extract the release notes from the current tag. The
>> problem with some repositories is that, they do not use annotated
>> tags, so I cannot extract the Release notes from the tags. But I am
>> able to extract the Release Notes from activity NEWS. I added this
>> feature in the past week, maybe it went unnoticed.
> I don't like having the creation of a version tag cause things like
> this to occur.  It will just encouarge me not to use tags.
>
> A current version tag is not a usable concept, especially for
> repositories with multiple branches, that's why "release tag
> (publish)" is said; so that a tag like "publish" or "aslov4" might be
> used instead.
>
> Yes, we don't typically annotate tags, but we do often have brief
> release notes in the commit that is tagged.
>
> Parsing from NEWS is probably sufficient for this specific list of
> activities.  I don't imagine it will number more than about 20.

Yes, I have done that for now. As far as I have noticed, and as far as I 
remember, the NEWS file of Implode Activity has its release notes in 
ascending order as compared to other activities where news are written 
in descending order. And in Implode, dates have been used. Should I 
include the capability to parse the release notes from those news too? 
but it will make the logic more complex.


>> To do some special testing / checking / checking out some commit or branch on
>> the activity, the generator gives the option as given below
>>
>> ```
>>
>>    --build-entrypoint BUILD_ENTRYPOINT
>>                          Specify a path to any Linux compatible script which is
>> intended to be executed on every build
>>    --build-override      Override `python setup.py dist_xo` with
>> --build-entrypoint argument shell script
>>    --build-chdir         Changes directory to Activity dir
>>
>> ```
>>
>> It implies, we could feed a custom build script, instead of using `python
>> setup.py dist_xo` . So I hope that would do!
>>
>> The idea of automatic building was to
>>
>>    • increase the quality of activity (I will extend this to testing activities,
>>      (make sure it starts) using Continuous Integration)
> I don't like the idea of automation that removes responsibilities of
> an activity maintainer.
>
Yes, but as far as I know, we have very few active maintainers for an 
activity. Anyways, I have added the support of manually building and 
deploying xo's and extracting the information, so do let me know if I 
need to add more features.


>>    • an activity built on your system, should be equally built on another
>>      developer's system (i.e should be reproducible)
> I don't see why we need to have bundles reproducible.  Bundles are
> made so infrequently.

:D

>>    • Reduce the time needed by developers to manually fill in the details and,
>>      upload binaries etc etc. I have used the exact same principle used by the
>>      [1]https://appimage.org  You can see their pull requests, which
>>      automatically tests if the appimage would work on Ubuntu Xenial (the oldest
>>      LTS).
> Scripting easily handles uploads.  For Python 3 activities, I'd just
> use scp or rsync of the bundle file.  I have this in my local scripts
> already.
>
> For Python 2 activities, it was way more complicated than I wanted;
> because of aslov1, see
> https://github.com/sugarlabs/sugar-tools/blob/master/activity-publish
>
> I don't want to be in a situation where release is dependent on a
> large collection of tools that have to work just right.  It can get
> fragile, and we don't release activities enough to justify that
> fragility.

Ok, in this case, there is no script that needs to exist on the client / 
activity builder's side. The appstore generator should be only deployed 
on the server / on the person's PC who is building the appstore.



>> Please let me know if there is anything I can do. I will try to get a server
>> (temporarily) to add the ssh feature.
>>
>> On 30/06/2020 09:24, James Cameron wrote:
>>
>>      On Tue, Jun 30, 2020 at 12:22:41AM +0300, Srevin Saju wrote:
>>
>>          Thanks
>>
>>              Yes, there is no single source of Python 3 activity bundles.  There
>>              was for Python 2 activities; it was activities.sugarlabs.org.
>>
>>          I hope aslov4 would solve this issue. I have now uploaded entire
>>          successfully built Python3 bundles to
>>          [2]https://github.com/srevinsaju/sugar-activity-build/  releases. You
>>          can check them out if you are interested and get some spare time.
>>
>>      Thanks.  That there is no single source of Python 3 activity bundles
>>      doesn't really cause a problem for me.  I don't need aslov4 to fix it.
>>      There's more to the dependency problems than Python version.  That's
>>      why I said in the aslov4 idea "(a) ported to Python 3 and released,
>>      and (b) tested on Sugar Live Build."
>>
>>              Yes, there is no single source of activity sources.  Best we have is
>>              GitHub sugarlabs org, where directory activity has a file
>>              activity.info which has a valid exec key.  But also gitorious.
>>
>>          By 'no single source', is there any instance of python3 activities on
>>          gitorious?
>>
>>      You'd have to look.  I don't know of any.  Ibiam is probably right,
>>      but as Gitorious is still open, commits may be pushed, and so there is
>>      a possibility that a repository there may contain activity source
>>      compatible with Python 3.  I don't think you need to concern yourself
>>      with it though.
>>
>>          I wanted to know if all the python3 activities are either forked or
>>          owned as a repository at sugarlabs GitHub organization? or does it
>>          still exist at some other places?
>>
>>      You'd have to look.  There can be activities for Sugar that are not
>>      part of the GitHub sugarlabs organisation.  We have seen several over
>>      the years, and we try to fork them, but there's no guarantee that we
>>      have been successful.  I don't think you need to concern yourself
>>      with it though.
>>
>>      Remember that in my design for aslov4, it must "support activity
>>      bundles uploaded via ssh," and may also "for a specific list of
>>      activities, access the source repository and detect any change to a
>>      release tag (publish), create a bundle and extract release notes,"
>>
>>      I'm looking forward to those two features in particular.
>>
>>      Some source repositories are used to make multiple activity bundles;
>>      Wikipedia and TamTam are examples.
>>
>>      I'm not interested in GitHub integration, because I don't always use
>>      GitHub, and some of the use cases for aslov4 are for situation where
>>      no internet access is available.
>>
>>              Yes, aslov4 as specified in our GSoC project idea could look like it
>>              was a smaller than normal project, but if you iterate through each of
>>              the requirements it could easily fill the time available for a GSoC
>>              student working for 12 weeks of seven hours a weekday.
>>
>>          Yes I agree. ASLOv4 is not an easy task. I am not sure when Manish
>>          (radii.dev) would be free, I will try to complete the best I can, to
>>          my knowledge.
>>
>>      Thanks.
>>
>> --
>> V/r
>> Srevin Saju
>>
>> References:
>>
>> [1]https://appimage.org/
>> [2]https://github.com/srevinsaju/sugar-activity-build/
> pub   RSA 4096/66D390D7 2020-05-19 Srevin Saju (srevinsaju)<srevinsaju at sugarlabs.org>
>> sub   RSA 4096/14479587 2020-05-19
>>
>
-- 
V/r
Srevin Saju

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20200702/a302cdca/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x1007816766D390D7.asc
Type: application/pgp-keys
Size: 4849 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20200702/a302cdca/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20200702/a302cdca/attachment-0001.sig>