Compiling schemas not part of the application template

Bug #976817 reported by Dražen Lučanin
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Quickly
New
Undecided
Unassigned

Bug Description

I am trying to work on a Quickly project created after the ubuntu-application template from PyDev. Now, this process is currently quite hard for several reasons:

- there is no "entry python script" that can be launched simply (the bin/<project_name> is the same name as the main code module which causes attribute errors, it doesn't have a .py extension etc.)
- the settings schemas are handled inside the quickly run command which makes the program depend on quickly; running just the bin/<project_name> in a terminal causes a missing schema error

In my oppinion, a partial solution would be:
- create a script called bin/<project_name>_dev_launcher.py or something similar so that users can run the project easily from external IDEs
- add the snippet from quickly's run.py to compile the schemas to this dev_launcher:
### BEGIN inserted from Quickly's run.py
# Compile schema if present
schemapath = os.path.abspath("data/glib-2.0/schemas")
if os.path.exists(schemapath):
    subprocess.call(["glib-compile-schemas", schemapath])
### END

This still requires from the user to append ":/path/to/your/project/data" to XDG_DATA_DIRS manually (can't this be solved more elegantlly?), such as by setting this environment variable inside PyDev's launch configuration, but at least no files must be editted after creating a project.

All in all, I think the goal should be for the project generated from a Quickly template to be completely autonomous of Quickly itself for all development runs, tests etc. to enable various workflows for this and not just manually editing the files and using a terminal.

Ideally the Eclipse's .project file could be generated as well to enable the user to import the project straight to Eclipse. It's 2 XML files, really nothing complicated. Something like 'quickly ide' to launch it comes to mind :)

description: updated
Revision history for this message
Tony Byrne (tony-badwolf) wrote :

Hi Dražen
 You spotted a design feature in quickly, it acts as its own ide and is tightly coupled with gedit . The quickly developers have even made a few trys at getting quickly to automatically load some ide extensions into gedit. The projects built with quickly are really only complete and stand alone after they are packaged. Using the source tree requires you use quickly run.
 You have discovered the steps needed to integrate with eclipse but as there are many ide choices I suggest we look at using 'quickly add pydev' as the suitable command.

 What I suggest for getting your perfect work flow is to create a toolkit for pydev integration
$ quickly quickly ubuntu-cli toolkit
copy the add.py command from ubuntu-application into your toolkit
$ cp /usr/share/quickly/templates/ubuntu-application/add.py ~/quickly-templates/toolkit
$ mkdir ~/quickly-templates/toolkit/store
then put the necessary code mentioned above into ~/quickly-templates/toolkit/store/pydev.py

After that you can run
$ quickly -t toolkit add pydev
 within any of your projects. When the "add pydev" command is perfected submit a patch, then you won't need the "- t toolkit" parameter.

Revision history for this message
Tony Byrne (tony-badwolf) wrote :

Hi Dražen
 On second thought would the entry problem and the path manipulation go away if pydev called a bash script

cd <project>
quickly run

as the entry point?

 If it has to be a python script you could use subprocess. There may be a packaging difficulty for the entry point. Can the entry script be hidden e.g. .run.sh or .run.py ?

Revision history for this message
Dražen Lučanin (kermit666) wrote :

Hi Tony,

thanks for replying so quickly (notice the word play ;)

Yes, I will try creating my own template and see if I can squeeze all the dependencies in it. Thanks for the instructions.

As for the entry point, I think monitoring a python process started by the quickly run command might be difficult in PyDev. It currently has to be configured manually for multiprocess applications and is not that user-friendly (http://pydev.org/manual_adv_remote_debugger.html). It could probably be handled somehow in the Eclipse launcher code to make it automatic, but I think they wouldn't accept a patch that was so specific.

I still think having some sort of dev-script to start it all up would be more ellegant. Imagine the scenario of someone who doesn't have quickly installed (maybe a Windows user?) branching the code to run it only to discover that he can't do it. The entry script could maybe be hidden (not sure how Eclipse sees such files, have to check) or we could create some rule for packaging to ommit this script (and the user should be notified through some comment inside this script not to edit it - that it's there only as a launcher during development).

Revision history for this message
Tony Byrne (tony-badwolf) wrote :

Hi Dražen
 There is very little in bin/foo, it simply calculates the path to the python files depending on whether the project is installed or not.

 Seeing how bin/foo cannot be called from pydev easily how about
ln -s bin/foo bin/pydev-run.py
then you could create your pydev-entry.py file which does your pre-processing, glade xdg etc, then import pydev-run. The "quickly add" system actually patches the project files so could easily exclude these pydev* files from packaging. The assumption is that a project might process command line arguments so quickly uses subprocess. I assume pydev has its own way to handle that.

Revision history for this message
Tony Byrne (tony-badwolf) wrote :

Hi Dražen
 Another point, ubuntu-application projects will not work outside ubuntu because they depend on launchpad-integration see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589008 So using a source tree for outside ubuntu is not trivial.

Revision history for this message
Michael Terry (mterry) wrote :

So, to the important issue of whether a quickly app depends on quickly or not, it definitely does not. During development, yes it does. But if you run "quickly package", it will create a deb file that does not depend on quickly.

The problem is that some files like schemas and images and such need to either be in a certain place on disk (requiring root access and messing with your system) or need various environmental variables set to point at the right places.

So that's what the wrapper script does. It has two modes (running as developer and running on system -- i.e. 'quickly run' or 'quickly package').

So it sounds like this bug is really about PyDev and quickly not having good integration?

Revision history for this message
Dražen Lučanin (kermit666) wrote : Re: [Bug 976817] Re: Compiling schemas not part of the application template

Michael,

well, yes. That's the main issue - integrating PyDev (or some other Python
IDE) and Quickly efficiently. But I think this is a worthwhile cause -
making it easy for developers (at whom Quickly is targeted) to start coding.

2012/4/10 Michael Terry <email address hidden>

> So, to the important issue of whether a quickly app depends on quickly
> or not, it definitely does not. During development, yes it does. But
> if you run "quickly package", it will create a deb file that does not
> depend on quickly.
>
> The problem is that some files like schemas and images and such need to
> either be in a certain place on disk (requiring root access and messing
> with your system) or need various environmental variables set to point
> at the right places.
>
>
> package').
>
> So it sounds like this bug is really about PyDev and quickly not having
> good integration?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/976817
>
> Title:
> Compiling schemas not part of the application template
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/quickly/+bug/976817/+subscriptions
>

Revision history for this message
Tony Byrne (tony-badwolf) wrote :

Hi Michael
 Actually I have come to agree with Dražen. The bin/project_name file has always had a path and environment manipulator for running in "trunk" a.k.a. source tree, but the introduction of gtk3 uses run.py for this as well. I think this section in run.py and create.py

    datadir = os.path.abspath("data")
    if 'XDG_DATA_DIRS' in env:
        env['XDG_DATA_DIRS'] = "%s:%s" % (datadir, env['XDG_DATA_DIRS'])
    else:
        env['XDG_DATA_DIRS'] = datadir

actually belongs in bin/project_name alongside this code in bin/project_name

if python_path:
    os.putenv('PYTHONPATH', "%s:%s" % (os.getenv('PYTHONPATH', ''), ':'.join(python_path))) # for subprocesses

both pieces of code do similar jobs.

The section in run.py and create.py
if os.path.exists(schemapath):
    subprocess.call(["glib-compile-schemas", schemapath])
looks ok where it is to me. I imagine a build command in pydev will need to do this.

The integration code I suggest go into quickly add pydev and best written by a pydev user (Dražen ?).

I would love to code a branch with this but unfortunately I broke a bone in my hand on Sunday so it's too hard.

Revision history for this message
Tony Byrne (tony-badwolf) wrote :

Hi all
I have a fix for this that puts this environment manipulation into bin/project_name along with other environment manipulation, see attached patch. With the patch in place a recent project can quickly run using versions 11.10 (pre gtk3) 12.03 and run standalone.

This bug was introduced in revision 645 "finally merge gtk3 branch" which manipulated the environment inside run.py then sent it throught the subprocess call to the project, while previously the project controlled its own environment.

Revision history for this message
Dražen Lučanin (kermit666) wrote :

Tony,

I tried your patch and I can confirm that it works. I can now run an application directly in a Python interpreter:

$ python bin/project_name

A step towards more IDE-freedom :) Over the next couple of days I'll see how it plays with PyDev and see if I can make some new branch with better integration. What is the desired workflow - branching trunk on lp:quickly or branching lp:ubuntu/quickly?

---

P.S. - do you know why I had to manually input the path to the file that is to be patched? I was inside the quickly project directory (with the README, bin/, data/ ... folders), issued:

$ wget https://bugs.launchpad.net/quickly/+bug/976817/+attachment/3069953/+files/976817-schemas.patch
$ patch -p1 < 976817-schemas.patch

and it always asked me to manually enter the file to patch, saying "can't find file to patch at input line 4". After I enter the same path that is stated in the patch it works.

Revision history for this message
Tony Byrne (tony-badwolf) wrote :

Hi Dražen
 I don't usually use patch so I can't answer you. I usually branch, test, edit, test, commit and submit, but that often fails just before a new release because I'm out of date on some dependency.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.