I would like to clean up the repository / working copy directory
structure. For example:

* Rearrange things such that the roundup/ directory matches exactly what
gets installed as the 'roundup' package.

* Move the content of roundup/scripts/ to scripts/, and clean up files
therein. (Some appear defunct, some obsolete)

* Move all data (tracker templates, compiled locale support files, etc.)
into share/roundup

* Refactor setup.py by moving the various build commands into
roundup/dist/command/, moving the release notes into NEWS.

* ?

Please note that this should have little or no impact on where Roundup
is installed, and so this only affects developers, but not users. In
fact, most of the proposed changes simply make the directory structure
more similar to how an installed Roundup would look like.

The overall goal is to clarify the purpose of individual files /
directories, and make project (and in particular, release-) management
simpler.

Comments are appreciated.

On Mon, Feb 23, 2009 at 10:23 AM, admin <issues@roundup-tracker.org> wrote:
> New submission from admin <roundup-admin@localhost>:

Note the above sender information...

> I would like to clean up the repository / working copy directory
> structure. For example:
>
> * Rearrange things such that the roundup/ directory matches exactly what
> gets installed as the 'roundup' package.

Such as?

> * Move the content of roundup/scripts/ to scripts/, and clean up files
> therein. (Some appear defunct, some obsolete)

Er, no. The point of that directory is that the scripts installed are
thin files which invoke the code in the roundup library scripts
package.

> * Move all data (tracker templates, compiled locale support files, etc.)
> into share/roundup

Sure - have you figured where "share/roundup" is on Windows and OS X?

> * Refactor setup.py by moving the various build commands into
> roundup/dist/command/, moving the release notes into NEWS.

Yep, sounds good.

OK, I understand the difference between installed scripts and scripts
merely useful to developers. But why not simply tell via setup.py which
ones to install ?

As to share/roundup, I'm not sure about Windows. I know that it works
just fine in other Python packages (including Synopsis, where I set it
up exactly the way I propose here).
I figure distutils knows best where these things are to be installed,
for each platform.

On Mon, Feb 23, 2009 at 12:21 PM, Stefan Seefeld
<issues@roundup-tracker.org> wrote:
> OK, I understand the difference between installed scripts and scripts
> merely useful to developers. But why not simply tell via setup.py which
> ones to install ?

I'm not sure I follow. setup.py only installs scripts it generates. It
doesn't install any scripts which actually exist on disk.

> As to share/roundup, I'm not sure about Windows. I know that it works
> just fine in other Python packages (including Synopsis, where I set it
> up exactly the way I propose here).
> I figure distutils knows best where these things are to be installed,
> for each platform.

OK

Richard,

rev:4160 contains the refactored setup.py script. I didn't change any
file locations yet, so this should work just as fine as before (I notice
some errors during rpm generation due to installed but unpackaged
compiled python modules (.pyc and .pyo). Will look into that later...)

I Created a new 'NEWS.txt' file for release notes, and dramatically
reduced the 'long description' to setup. Let me know if you think it's
now not long enough. (I don't think it makes sense to put release-notes
into the description, neither upgrading hints nor pointers to where to
download the package from. The reader of that text will already know. :-) )