[Sugar-devel] no module named sugar.activity.activity

[Abhishek Tanwar]

I am trying to port https://github.com/sugarlabs/arithmetic to GTk3 but
when i run the activity to understand the working(with GTK) it throws an
error "no module named sugar.activity.activity".I searched google for any
potential solutions but could not find anything .

Traceback (most recent call last):
  File "/usr/bin/sugar-activity", line 219, in 
main()
  File "/usr/bin/sugar-activity", line 214, in main
instance = create_activity_instance(activity_constructor,
activity_handle)
  File "/usr/bin/sugar-activity", line 48, in create_activity_instance
activity = constructor(handle)
  File
"/usr/share/sugar/activities/compress-activity.activity/Compress.py", line
42, in _init_
canvas = PyApp()
  File
"/usr/share/sugar/activities/compress-activity.activity/CompressCanvas3.py",
line 504, in _init_
if Gdk.Screen.width() >= 1200:
NameError: global name 'Gdk' is not defined
Exited with status 1, pid 1692 data (', mode 'w' at
0x7f0fd82a3ae0>, 'f5b6d864dcbea56c6345d8d0394716abe77d46e7')


I setup my development environment by following
https://github.com/sugarlabs/sugar/blob/master/docs/ubuntu.md and I am
working on ubuntu 18.04.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] getting the Sugar Toolkit working with python 3

[James Cameron]

Thanks.  Really interesting; I learned a few things from your
research.

One of the problems I faced when whipping up Sugar Live Build on
Debian was how our dependencies *do not* easily support using unusual
paths.  Dependencies such as;

* Xsession, for starting Sugar itself,

* D-Bus, for starting an instance of sugar-datastore aka carquinyol,

* pkexec, for reading and writing display backlight levels.

I found it simpler to move the files to where they can be used than
to reconfigure each of these dependencies.

Next step to avoid the cognitive dissonance is to build custom
packages of Sugar and add them to the live build.

I had hoped to figure out from Debian how to do this, but progress has
been slow; at the moment in Debian and also consequently in Ubuntu
19.10

* sugar-toolkit-gtk3 for 0.116 is packaged (Python 2 and Python 3),

* sugar for 0.112 is packaged (Python 2 only).

These are incompatible, and Sugar does not start.  It's one of those
mine canary things; it has been this way for months and nobody has yet
reported a bug to Debian.  Therefore there are no testers of Debian
who focus on Sugar.  That will be a good enough reason for Sugar to
disappear from Debian, as had almost happened in Fedora.

For upcoming 20.04, the Ubuntu team has removed most of the Sugar
packages.  Perhaps I like this because I can then supply my own and
not have conflicts.  ;-)

On Tue, Jan 28, 2020 at 05:23:31PM +, D. Joe wrote:
> 
> OK, in the face of my unease with seeing someone doing that (modifying files 
> in directories under package-management control) anywhere but in an isolated 
> dev environment (container or chroot), I think I've finally grasped a second 
> dimension to the Python path situation, particularly as it applies to Debian 
> (and by extension, to Ubuntu).
> 
> There are two ways, generally speaking, to address this sort of problem: 
> Either a) put the files where your installation of Python is looking for them 
> (what's been done in the example upthread), or b) tell your installation of 
> Python any new locations in which it should look for the files.
> 
> What we've been trying to do is put the files in a directory set aside by 
> Debian policy as a place for Debian packages to put their modules. [10][10], 
> [20][20]
> 
> I *had* thought Debian (with, presumably, Ubuntu following suit) uses paths 
> containing `dist-packages` so as not to conflict with the default from the 
> Python project upstream, which is to use `site-packages`. [30][30] 
> 
> We've been discussing how best to handle these differences for a little while 
> now. [40][40], [50][50]
> 
> For instance, `sugar-live-build` currently transfers files from one 
> `site-packages` directory to the parallel `dist-packages` directories for 
> `sugar3`, `carquinyol`, and `jarabe` using `rsync` or `mv`. [60]
> 
> James pointed out Debian bug report 765022 in earlier discussion, but I only 
> just now absorbed the lesson from the last response of the Debian developer 
> there.[70]
> 
> There are two dimensions to consider: 
> 
> The first is whether or not Python module files are installed under control 
> of the distribution's package manager using the distribution's .deb package, 
> or built and installed by the system administrator from source. I had 
> misattributed the `dist-packages` vs `site-packages` difference as addressing 
> this dimension, but I was wrong. The file system distinction between 
> `/usr/lib` versus `/usr/local/lib` is meant to address this dimension, and 
> continues long-standing practice.
> 
> The second dimension is the attempt to make sure that the Python files match 
> the python executable being used. Debian tries to accomodate the possibility 
> that the sysadmin or user would try to use a python executable other than the 
> one installed by the distribution. We use the distribution-supplied python 
> interpreters (eg, `/usr/bin/python` and `/usr/bin/python3`), so this question 
> hasn't arisen for us and may be why I missed seeing the distinction. 
> 
> It is to address this difference that the `dist-packages` versus 
> `site-packages` distinction has been made by Debian (and inherited by 
> Ubuntu). The first is meant for use by the python interpreter(s) that have 
> been installed from the **distribution**'s packages, whereas the latter is 
> meant to be used by those installed at the local **site** from upstream 
> Python project sources, using their defaults, by the sysadmin (presumably 
> this site-specific binary would also be installed in /usr/local, which is 
> where a further opportunity for confusion arises)
> 
> So, I wonder if the right place to put packages when built locally not for 
> distribution as .deb files is to put them in 
> `/usr/local/lib/python3/dist-packages` or 
> `/usr/local/lib/python2.7/dist-packages` The Debian reference says the 
> interpreter will look in `/usr/local/lib/python3/site-packages`[10][10] so 
> I'm not sure how to reconcile that with the discussion 

[Sugar-devel] Last few days to vote for the Sugar Labs Oversight Board Elections!

[Vipul Gupta]

Hello folks,
This is the last reminder to vote for the Sugar Labs Oversight Board
Elections 2019-21. The election closes on the 31st of January 2019. The
results will be declared soon after that. If you are still waiting to vote
and then the time is now. Better hustle because every vote counts!

Looking forward to everyone's participation in the election!
As always, reach out if you have any questions. Thanks,

Best,
Vipul Gupta
Mixster  | Github

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Ideal futures for the "I Know" Sugar activities

[James Cameron]

On Tue, Jan 28, 2020 at 08:09:00PM +0530, Rahul Bothra wrote:
> On Tue, Jan 28, 2020 at 11:48 AM James Cameron  wrote:
> >  I'm also not sure how else the activity sources have diverged.
> 
> As long as we can achieve the same user experience, I'd recommend
> that we ignore comparing changes made in each of the sources. There
> are better things that a developer's time could go into.

True, but without some cursorary comparison we wouldn't know if we
dropped a feature or bug fix.

> With that said, the best way to ensure we don't skip any portion of
> the experience is to check the source history ;-)

Unfortunately, some of these sources don't have a commit history.

So comparison could be;

- convert line endings,

- autoformatting, (only for the purposes of comparison, as divergence
  in code format or style is a really useful indicator of change or
  mixed authorship),

- recursive diff(1) or visualisation tools like meld.

-- 
James Cameron
http://quozl.netrek.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] getting the Sugar Toolkit working with python 3

[D. Joe]

OK, in the face of my unease with seeing someone doing that (modifying files in 
directories under package-management control) anywhere but in an isolated dev 
environment (container or chroot), I think I've finally grasped a second 
dimension to the Python path situation, particularly as it applies to Debian 
(and by extension, to Ubuntu).

There are two ways, generally speaking, to address this sort of problem: Either 
a) put the files where your installation of Python is looking for them (what's 
been done in the example upthread), or b) tell your installation of Python any 
new locations in which it should look for the files.

What we've been trying to do is put the files in a directory set aside by 
Debian policy as a place for Debian packages to put their modules. [10][10], 
[20][20]

I *had* thought Debian (with, presumably, Ubuntu following suit) uses paths 
containing `dist-packages` so as not to conflict with the default from the 
Python project upstream, which is to use `site-packages`. [30][30] 

We've been discussing how best to handle these differences for a little while 
now. [40][40], [50][50]

For instance, `sugar-live-build` currently transfers files from one 
`site-packages` directory to the parallel `dist-packages` directories for 
`sugar3`, `carquinyol`, and `jarabe` using `rsync` or `mv`. [60]

James pointed out Debian bug report 765022 in earlier discussion, but I only 
just now absorbed the lesson from the last response of the Debian developer 
there.[70]

There are two dimensions to consider: 

The first is whether or not Python module files are installed under control of 
the distribution's package manager using the distribution's .deb package, or 
built and installed by the system administrator from source. I had 
misattributed the `dist-packages` vs `site-packages` difference as addressing 
this dimension, but I was wrong. The file system distinction between `/usr/lib` 
versus `/usr/local/lib` is meant to address this dimension, and continues 
long-standing practice.

The second dimension is the attempt to make sure that the Python files match 
the python executable being used. Debian tries to accomodate the possibility 
that the sysadmin or user would try to use a python executable other than the 
one installed by the distribution. We use the distribution-supplied python 
interpreters (eg, `/usr/bin/python` and `/usr/bin/python3`), so this question 
hasn't arisen for us and may be why I missed seeing the distinction. 

It is to address this difference that the `dist-packages` versus 
`site-packages` distinction has been made by Debian (and inherited by Ubuntu). 
The first is meant for use by the python interpreter(s) that have been 
installed from the **distribution**'s packages, whereas the latter is meant to 
be used by those installed at the local **site** from upstream Python project 
sources, using their defaults, by the sysadmin (presumably this site-specific 
binary would also be installed in /usr/local, which is where a further 
opportunity for confusion arises)

So, I wonder if the right place to put packages when built locally not for 
distribution as .deb files is to put them in 
`/usr/local/lib/python3/dist-packages` or 
`/usr/local/lib/python2.7/dist-packages` The Debian reference says the 
interpreter will look in `/usr/local/lib/python3/site-packages`[10][10] so I'm 
not sure how to reconcile that with the discussion in the Debian bug [70][70] 
other than to note that the bug report is old or that the documentation may be 
stale. Even so, putting things in `/usr/local/` still seems the way to go? 

This is all still consistent with observations that 
`/usr/lib/python3/site-packages` did not work, because why would any 
distribution-supplied packages (the `/usr/lib` part) ever be made to work with 
a python binary version installed by the site sysadmin (the `site-packages` 
part)?

I'm just now getting to the Fedora docs about this.[80][80] They bring up the 
further question of architecture-depended paths (eg, `lib` vs `lib64`) versus 
arch-independent things (going in `share` rather than `lib`). 

Fedora is also out in front on the attempt to merge things from the `/usr` 
hierarchy (eg, everything mentioned above) up into the corresponding top-level 
filesystem directores (eg, into `/lib` instead of `/usr/lib`, `/bin` instead of 
`/usr/bin`). So who knows how much attention has withered in the face of these 
added dimensions.[90][90]

A quick check on the machine at hand:

```
$ cat /etc/os-release 
NAME="Ubuntu"
VERSION="18.04.3 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.3 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/;
SUPPORT_URL="https://help.ubuntu.com/;
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
$ python
Python 2.7.17 (default, Nov  7 2019, 10:07:09) 
[GCC 7.4.0] on linux2
Type 

Re: [Sugar-devel] Ideal futures for the "I Know" Sugar activities

[Rahul Bothra]

On Tue, Jan 28, 2020 at 11:48 AM James Cameron  wrote:
>  I'm also not sure how else the activity sources have diverged.

As long as we can achieve the same user experience, I'd recommend that we
ignore comparing changes made in each of the sources. There are better
things
that a developer's time could go into.

With that said, the best way to ensure we don't skip any portion of the
experience is to
check the source history ;-)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel