Welcome, Guest. Please login or register.

Pages: [1]
Print
Author Topic: Reorganizing the Directory Structure  (Read 2931 times)
aspidites
Community member

Posts: 29


View Profile Email
« on: February 14, 2011, 08:52:32 AM »

Summary:
What would you recommend as a directory structure for PARPG's source code and documentation?

Detail:
In trying to contribute to PARPG, I have found that the current directory structure prevents me from continuing work.

For example:
* the dialogue editor that I am working on needs to wrap a few of PARPG's objects in order to represent data correctly.
* the cleanest way to gain access to those objects without duplicating them in the file system would be to import them, which requires them being available on the system.
* in order for them to be available on the system, there has to be a standard way to install PARPG, which there isn't
* the simplest way to install PARPG on a user's system is through the use of distutils and friends (py2exe, py2app), which requires a sensible directory structure.

For the purpose of resolving (or at least regaining the ability to work toward resolving) the above issues, dramatic restructure is not necessary. Instead, only minor renaming needs to be done. However, at some point, I think we should evaluate the structure itself in an effort to ease the task of packaging and make it easier for people to find relevant information.

As it stands now, the package that has all of the importable modules is called scripts, which means that a typical import line looks as follows:
Code:
from scripts.dialogue import *
# or
import scripts

I think it would be much more desirable if we followed FIFE's lead and rename the package 'parpg':
Code:
from parpg.dialogue import *
# or
import parpg

While not strictly a name class, the pre-existence of a module named parpg might make it a bit awkward for some developers:
Code:
from parpg.parpg import *

I haven't an ideal name for this module unfortunately, but I was thinking perhaps 'core':
Code:
from parpg.core import *

The only other name that would be bizarre for packagers is the run.py script itself. We could either add it to the scripts directory and create a bash/batch file to invoke it, or simply rename it something else, like just parpg (without the extension). Not doing so would mean you would end up (on unix systems) having an exicutable called run (/usr/bin/run) which is odd.

What are your thoughts for the short term and the long term? That is, as a means to allowing the above tickets to be resolved, what changes would you propose, and for the future, what kind of directory structure would you propose?
Logged
Technomage
Admin
Community member

Posts: 80



View Profile
« Reply #1 on: February 18, 2011, 08:43:35 PM »

I fully support renaming the "scripts" directory to "parpg", it makes a lot of sense in my mind. You'd have to do a find-replace on all imports though and change them.

Renaming the parpg.py module to core.py is fine by me, but perhaps a more descriptive name like "application.py" would be better suited. E.g.
Code:
from parpg.application import PARPGApplication

run.py just needs to be renamed to, e.g. "parpg.py". Its fine as an entry point in my mind, lots of python applications use a python script as an entry point. Might be able to move a bit of the logic it defines to the PARPGApplication class though.
Logged

"There are more atoms in the period at the end of this sentence than you can count in a lifetime." Science is awesome.

aspidites
Community member

Posts: 29


View Profile Email
« Reply #2 on: March 07, 2011, 04:17:24 AM »

I've pretty much finished packaging PARPG for Linux and Windows, but left a few files out of the package because I wasn't sure where they should go.  I have ideas, but am waiting for input before I proceed.

Here are the unpackaged files:
AUTHORS [1]
design/ [2]
dialogue_schema.yaml [2]
dialogue_demo.py [2]
license/ [1]
parpg_editor.py [3]
pylintrc [2]
README [1]
run_tests.py [2]
tests/ [2]
tools/ [2]

* [1] I'm wondering if these should be installed in the root installation directory, or if they should reside in a docs/ subdirectory
* [2] These all seem to be development related only. As such, I'm not certain they belong in a distribution at all. Unless perhaps we had a package called "parpg-devtools" or similar.
* [3] None of the tools are mature enough for packaging I think. When tehy are , i think they should be their own package.

I almost think it makes since to move items from  [2] above to a top-level directory like "testing" or similar.

Opinions?
Logged
zenbitz
Community member

Posts: 1164



View Profile
« Reply #3 on: March 11, 2011, 12:19:24 AM »

I think the README and INSTALL (which there should be one) etc. should be in the root dir of the dist.  Along with any make/scons/whatever files... as if it was an rpm or what have you.

Dev tools can just go in tools/.   They could be left out of a "demo" release distribution branch.
Logged

We are not denying them an ending...
We are denying them a DISNEY ending - Icelus
Pages: [1]
Print
Jump to: