Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

Sorry about the wall of text, but I am trying to provide a good background to my question. Actually, there are like a million questions here because I am utterly confused. I recently learned some Python programming and made a Windows application. Now I want to implement that app and a few other ideas for Ubuntu and release them as open source GPL-3. Although, I would like to keep the code possible to run on any system (or at least both Ubuntu and Windows).

So to learn how Ubuntu packaging works, I've looked at the quickly application used in the App Developer Showdown recently. But the folder structure and the files it creates makes no sense at all to me. So I read the Ubuntu Packaging Guide and the Applicaton Review Process with all the links there, as well as the Debian Python Policy. But all that text just worked to make me more confused about the way quickly creates files and folders.

The quickly way?

So, this is what I understand from quickly (assuming my project name is proj):

proj/bin = one single file that will be copied to /usr/share/bin/proj.py to enable running the app from a global path? But that would be in violation of the "Application Review Process" rules, right?
proj/data/* = files that should go under /usr/share/proj/*, right? But that would also be in violation of the "Application Review Process" rules?
proj/help/C/* = some HTML documentation, I think, which should go under /usr/share/doc/proj/ and that works well with "Application Review Process", but why is the folder name "C" and not just "proj"?
proj/tests/ = some sort of files for a "test" package within Python. I guess this is great, looking forward to learn what it is.
proj/proj/ = some files that just seem to link to new files in the proj_lib folder? Seems unnecessary, and I don't understand why these are here at all.
proj/proj_lib/ = the actual source code, I guess?

Then quickly also creates proj/apport and proj/etc/apport* which I have no idea what they do or why they are added.

Now, the really confusing part is the file structure. It looks like nothing I have seen before. And to be honest, it looks very complicated in an unnecessary way. Below this section I will describe the way I would make my own project file structure, which may help describe why this is so confusing to me. But first, my understanding of the quickly way (note that my understanding may be wrong at this point).

First of all, the setup.py. This file contains a function called update_config() which just loads another file called proj/proj_lib/projconfig.py. But that config.py-file doesn't seem to contain anything that would be useful to keep separate from the setup.py? Actually, there are a lot of things that I've never seen anyone suggest to put in a setup.py-file before. The setup.py also contains a hard coded file name pointing to the SVG icon, and otherwise just copies the desktop.in-file on itself so why not just have the changes made directly in the desktop.in-file without this function in setup.py? Then there is another function to create a subdirectory proj/data/share/proj and copy the desktop.in-file there, which I don't understand the purpose of? Why have a function that does that when you can just have the file there originally? Then after all of this nonsensical code comes something that actually looks like a regular setup.py.

Now the proj/bin/proj.py, which I assume is supposed to be used to start the application? This just seems to remap /usr/ to /opt/extras.ubuntu.com/ in a previously undeclared syspath variable. So I guess this is to accomodate the rules in the "Application Review Process" for apps that are using folder names standard for all other Linux flavors? Fair enough, I don't understand it but I can live with that. After this remapping of directories, this file goes on to call on proj/proj/init.py.

proj/proj/__init__.py is the standard way to define how to start a module, I guess? But instead of having some code which actually does something, this file just goes on to in turn run the main window class, which is located in yet another file.

proj/proj_lib/ also has an init.py-file which I don't understand the purpose of. Then there is a Window.py which seems to contain the actually functionality of the application, and calls other window py-files like about dialog etc.

The way I did my app

My folder structure looks like this:

proj/
proj/ui
proj/imageformats # necessary for imports to work
proj/sqldrivers   # necessary for imports to work

In the proj/ folder I have my setup.py and my proj.py which starts my app. In my proj.py file I have all the main window functionality, calling some other windows and functions with imports, and at the end of this file is the main() function which starts the app.

The proj/ui/ folder contains all my .ui files made with Qt Designer.

The other folders are just there to provide some files which will make the application work when packaged with py2exe for Windows. Basically, they are the files that would be provided through dependencies in Ubuntu.

Note that this setup I have works great for Windows development. I use py2exe to build an executable that ends up in a proj/dist/ folder, and I can just copy the files in this folder and it will work on any Windows machine.

How do I combine this?

I have spent a few days trying to read documentation. There is hardly anything I can find on quickly, except the basic tutorial and the stuff on App Developer Showdown Workshops. I can't find anything there that helps me make sense of the folder structure suggested by quickly.

From what I have read, I could use os.environ['HOME'] to create a path to ~/.config/proj.conf on Ubuntu or C:/Users/username/.config/proj.conf on Windows. That far I can keep to cross platform code. But then with the division into /bin and /etc and /opt I will start to run into some problems. Of course, I could as a last resort keep two copies of the code - one set up for Ubuntu and one set up for Windows. But then I would still want a similar folder structure to make the transfer of code changes easy.

There should be someone who already has a good solution for this. And perhaps that person could also (besides giving an example of how to make it cross-platform) describe why there is such a long chain of files calling other files calling other files in the default quickly setup? Of course, I am now assuming that quickly uses some sort of recommended model for Ubuntu. If that is not the case, I would like to get suggestions on what would be a recommended folder structure to distribute an application through Ubuntu repositories?

share|improve this question

closed as not a real question by David Planella, con-f-use, John S Gruber, hbdgaf, jokerdino Aug 24 '12 at 3:13

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
Find a popular application, extract it, and see how they did it. –  Sepero Jul 11 '12 at 3:05
    
Moreover, this is not an Ubuntu-specific question -- it would better fit to stackoverflow IMHO (also better chances for good replies). You can have it moved over there AFAIK if it gets flagged accordingly. –  Izzy Jul 11 '12 at 8:47
    
AFAIK, quickly is an Ubuntu-specific application, and I am trying to use that to "see how they do it" as Sepero suggested. The rule about putting applications in /opt rather than /usr is Ubuntu specific. This is not a general question in that sense because it deals with specifics of how to distribute Python on Ubuntu (but still keep it open for other OS's). –  GaRyu Jul 11 '12 at 9:04
    
While on topic for Ask Ubuntu, this looks to me like a discussion to be had on the Quickly list launchpad.net/~quickly-talk, rather than a question. –  David Planella Jul 11 '12 at 16:14
    
I used the structure provided by quickly as an example, because I assume it is thought through. However, no matter how thought through it is there is no documentation explaining the thoughts behind it. Of course, this could be discussed on the Quickly list, as you say. But then, the question is not only about how quickly works. The question is, how do I set things up to conform to Ubuntu specifications (like quickly) while at the same time making it easy to run on Windows or other platforms? This is not quickly-specific in any way, it just uses quickly as a starting point for the discussion. –  GaRyu Jul 12 '12 at 9:31

1 Answer 1

After a lot of googling outside of Ubuntu-specific or Debian-specific pages, I found this one that was actually rather helpful. Basically, the suggestion is to keep it something like this:

proj/
proj/bin/proj.py                 # this will just "import proj" and "main()"
proj/proj/__init__.py            # this will just "import window.py" and run that
proj/proj/window.py              # main functionality
proj/proj/submodule/__init__.py  # import in window.py
proj/proj/test/                  # for that test package that quickly also uses
proj/README                      # basic readme file
proj/setup.py                    # standard distutils setup.py

This sounds more sensible to me than the quickly way, and closer to my original way of doing it. And it shouldn't be impossible to make it into a Debian package that follows the Ubuntu guidelines? So I think I will just erase the quickly stuff and do this. Unless anyone has a better suggestion?

What remains here then is "how do I set this up to install well on Ubuntu, as well as Windows?", i.e. should I code setup.py in a special way or make other considerations in the code...

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.