TwTools, a new home for ToscaWidgets
percious
I just wanted to let everyone know that I am currently under the
process of taking over maintenance of all of the ToscaWidgets projects
which currently reside at:
http://svn.turbogears.org/projects/
My plan is to move all of these projects over to:
http://twtools.googlecode.com/svn/projects/
If you are an owner/maintainer of one of these projects, and have a
compelling reason to leave it in the Turbogears trunk let me know! I
think for the time being ToscaWidgets and ToscaWidgetsForms are going
to stay, but anything with a "tw" is getting moved.
each project will be getting its own trunk/tags/branches directory.
Those of you who are still actively maintaining their projects will be
given access to twtools.
If the package is not registered with pypi, I will be registering it.
If the package *is* registered with PyPI, I would appreciate it if you
could add the user twtools to the project roles as an owner.
If you have a private tw project that you want to publicise, and need
to find it a good home, TwTools is here for you. Please just email me
or Mark Ramm and one of us will give you access to the twtools repo
and a project folder complete with trunk/tags/branches for your
project. The only thing we ask in return is that you either allow us
to register your project, or add twtools as a "owner" to your pypi
account.
Why should share my ownership? The fact is that tw projects are small
and are often times abandoned, because they hold little value by
themselves. However, collectively the ToscaWidgets libraries are
pretty valuable to the WSGI community. They save developers time and
provide a place to put your work if you move from company to company.
We want the ability to pass maintenance from one developer to the
next, especially as JS libraries move pretty quickly and there is a
need to stay up-to-date.
Finally, I am going to propose a "tw." pypi namespace. This will
allow a clean slate for projects that are abandoned and goes along
with the "z3c.blah" and "zope.blah" way of doing things (which I
rather like). Vote here to keep it twBlah or tw.blah. (I also think
getting rid of capitals is more PEP8 compliant)
This email is going to be duplicated somewhere in the TG
documentation.
cheers.
-chris
Christopher Arndt
> I just wanted to let everyone know that I am currently under the
> process of taking over maintenance of all of the ToscaWidgets projects
>
> to stay, but anything with a "tw" is getting moved.
Hi Chris,
that is good news! Just to clarify: are you the new maintainer also for
ToscaWidgets proper or just for tw* projects?
If you are the maintainer for ToscaWidgets also, what are your plans for
toscawidgets.org and beta.toscawidgets.org? Will they be merged with
your code.google.com site also? Or should we host them on the
turbogears.org server (the domain name should stay, IMHO)?
Since we decided to replace TG widgets with TW in TG 1.1 (see
1.1/DevPlans on the wiki), it would be important for us (us being the
1.1 release team), to have some form of influence over the TW release
process and documentation.
I'd appreciate your thoughts on this.
Chris
Alberto Valverde
Chris and I have been discussing this yesterday in this thread [1] in TW's
mailing list. The gist of it is that we're both going to be maintainers of
TW with full access to the cheeseshop and toscawidgets.org.
toscawidgets.org will act as the hub of the TW ecosystem hosting
repositories, docs, tracs, widget browser and other goodies.
toscawidgets.org is currently hosted in a VPS I own. However, I'm quite
amiable to the idea of moving it over to the VPS turbogears.org is hosted
at to have a larger pool of backup admins.
Alberto
[1]
http://groups.google.com/group/toscawidgets-discuss/browse_thread/thread/a2700123b7f0b9e0
percious
TwTools will continue to exist until beta.towcawidgets.org goes prime-
time. The target is May 1. There are 4 tasks we must complete before
going live.
1) create a user-registration form to make it easy for TW contribs to
add their projects to a central repo.
2) set up the Hg repo, and provide good documentation about how to use
the repository.
3) Make Trac available to contribs. (relates to 1 and 2)
4) Do some website cleanup.
This will allow GSoC students to keep working in the TwTools
repository (believe it or not some have actually started working
before the program starts!)
As for documentation. I will move over whatever is in TwTools when we
get to that point.
I think we are going to end up with a a great library of widgets,
capable of competing or exceeding anything currently available in the
web application community. TwTools is going to just be a hold over
while we get all the proper machinery in place.
-chris
Christopher Arndt
> 2) set up the Hg repo, and provide good documentation about how to use
> the repository.
Have you tested whether all the setuptools machinery works properly with
mercurial? AFAIK, the "include_package_data" setup() option only works
with CVS & SVN by default. Don't know if any TW widget uses this, but
this should be checked. Also, what about including "ez_setup.py" as a
repo external?
Chris
Alberto Valverde
TW and tw.forms use an adapted version of TG's "find_package_data"
function which searches the tree for static resources to include them in
the manifest so this works around that limitation. Including ez_setup.py
as a repo. external is not supported by Hg AFAIK but it doesn't suppose
much of a limitation IMHO since it can be imported directly and updated
manually.
Alberto
percious
version number in my release egg, and setuptools does this
automatically, by looking at the .svn folder and retrieving it. How
is this going to work with Hg? Tracking down errors with people's
widgets is going to get hairy unless we have some way of keeping track
of the version numbers.
About a setup folder: Gosh, I really hate when packages do that.
Haven't we all realized that our developers need to get with the
program and have easy_install working first? For this reason none of
my packages will contain a setup/ and if a paster script creates one,
I will promptly remove it. Maybe I am missing the problem that it
solves.
-chris
Alberto Valverde
> I didn't think of this problem. I personally really like having the
> version number in my release egg, and setuptools does this
> automatically, by looking at the .svn folder and retrieving it. How
> is this going to work with Hg? Tracking down errors with people's
> widgets is going to get hairy unless we have some way of keeping track
> of the version numbers.
setuptools can be configured to tag "dev" releases with the date instead
of the SVN revision. I haven't had any trouble in practice with it so
far (with in-house projects) since the comparison setuptools does to
determine if a version is newer than another works as expected. As for
"stable" releases, the same X.Y.Z notation scheme being used now can
still be used.
> About a setup folder: Gosh, I really hate when packages do that.
> Haven't we all realized that our developers need to get with the
> program and have easy_install working first? For this reason none of
> my packages will contain a setup/ and if a paster script creates one,
> I will promptly remove it. Maybe I am missing the problem that it
> solves.
If setup.py is properly setup (sic) it allows setuptools to be installed
automatically if it's not installed. I guess that now that setuptools is
more widely used and most probably anyone installing TW for the first
time has already a setuptools-enabled system (since TG/Pylons depends on
it) it doesn't matter so much anymore.
Alberto