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 --helpwill 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.
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.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.
• 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)<srevins...@sugarlabs.org>sub RSA 4096/14479587 2020-05-19
-- V/r Srevin Saju
OpenPGP_0x1007816766D390D7.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
