On Tue, 2005-09-20 at 17:35 -0400, Greg Steffensen wrote:
Ok, the clipartbrowser cvs module is now synched up again with the latest tarballs, and the cannonical download location for releases is now
http://www.python.org/pypi/clipartbrowser
(it used to be on Berlios). If you download a release (they work better than ever :), install using "python setup.py install" (assuming you have the dependencies met). The "easy_install" method mentioned earlier works too.
Cool...I still think you should do releases and use Inkscape's sf.net space just for the sake of affiliation and encouraging other developers who already have access to work with you.
Providing easy access to others is the key to getting more feedback and others hacking on your projects...and in order to take advantage of this, you should try to work in the community with the practices and traditions that the majority of developers know.
For example, I can work on your app when you use standard infrastructures, as I know standard Makefiles and packaging, but now am discouraged from working on clipartbrowser because I don't have time to learn "Yet Another Language."
How is the project going btw? I've been swamped in with new gigs -- teaching at sfai.edu and working at creativecommons.org
Jon
On 9/20/05, Greg Steffensen <greg.steffensen@...400...> wrote: I didn't explain the technical situtation with the install method very well. Basically, if I write a file "setup.py" that defines certain information, users should be able to execute "python setup.py install" to install the program correctly, and I should be able to execute commands "python setup.py bdist_win" to create actual win32 EXE files containing pretty automated installer GUIs. In addition, users will be able to install the way I described in the release email as well. In general, setup.py uses the "setuptools" which are the successor to the "distutils", which is the distribution/installation tools included with python. I'm still not certain whether I should use the setuptools or the older distutils, and am figuring stuff like that out, but they're both supposed to be the python-friendly replacement for Makefiles, and I'm trying to reorganize the code to do stuff the "correct" way.
Greg On 9/20/05, Greg Steffensen <greg.steffensen@...400...> wrote: Hey, yeah, this is kinda what I was referring when I said that the packaging isn't as polished as it needs to be. For what its worth, most of the changes (bug fixes, performance improvements) actually are committed to CVS; I just didn't commit commit the change in the install method simply because I was having trouble figuring out how to get files like COPYING, NEWS, etc. included using that method, and I didn't want to put a totally messed up version into CVS. Basically, I actually really released more on a whim, not because I'd worked everything out, but because I'd gone too long without releasing code, wanted people to know that work was ongoing. So, at a minimum, I should have indicated that this was definitely a development release. So, solutions... in terms of where formal releases (formal tarballs) should go, I actually think the python package index is definitely the correct place... its now the "official" place where the python folk reccomend that python projects be listed, and it will offer a number of technical advantages, including publication of new releases, and installation automation. I'm very happy keeping CVS at Inkscape though (not that PyPI offers CVS anyway), and treating the code as a subproject of Inkscape. But as long as it offers the ability to be installed standalone as well, I'd like to make standalone tarballs available from PyPI. In general, I'm learning more about python, and am trying to make my practices for installation, etc. match accepted practice. I'll try to get CVS synched up with the current state of the project very soon; I'm still having some trouble with the python installation tools, and have sent an email to their mailing list for advice, but haven't heard back yet. Once I know how to get the documentation files included, and where to put the main install file (setup.py), I'll get that committed and CVS will contain the official version of the code gain. Again, I would have waited until this was done to release, but just felt bad about having gone too long without releasing already, and was overeager to get something out. Anyway, does this cover the stuff you were concerned about? If not, let me know. Also, you may recall that someone posted a link to a mockup for a very similar project that they'd found, and I replied that this was "very depressing" :). I used that mockup to develop version 0.4, and emailed the designer (as the community suggested); he's finally written me back, and said he's interested in contributing, which rocks. Later, Greg On 9/19/05, Jon Phillips <jon@...235...> wrote: <offlist /> On Mon, 2005-09-19 at 05:20 -0400, Greg Steffensen wrote: > I'm releasing another version of the clip art browser. Lots of bug > fixes, some performance improvements, code cleanups, and a new > installation procedure (yes, yet another). > > Installation is now 3 steps, and hopefully easier than ever: > > 1) Satisfy the dependencies of Python 2.4 and PyGTK 2.6. > > 2) Download and run the following script, which installs the python > setuptools: > > http://peak.telecommunity.com/dist/ez_setup.py > > 3) Run "easy_install clipartbrowser" > > As you can see, I've switched the installation system from Makefiles > to the python setuptools. The setuptools are still under development > (they're apparently going to be included in python 2.5), and I'm still > very much learning how to use them, so the packaging isn't as polished > as it needs to be, but this makes installation a breeze. Eventually, > it should allow arbitrary python dependencies to be intelligently > installed as well using the same process. > > I'm still working on getting this integrated back into the Inkscape > effects menu, that's next on the list. As always, feedback greatly > appreciated. > Greg, I thought we were going to do the next release from Inkscape CVS? What you have done is a non-standard release of the project now that we consolidated the code into Inkscape. Also, you have now used a non-standard approach to packaging which then again breaks what users and developers are use to. The major thing though is that we were going to do a solid release which means you need to involve the people who would contribute to this in the release to help smooth out the bugs. Instead, now you have released from another location thus confusing users and developers more. The problem with this is that it is not pro-community. Anyhow, I'm curious what you think and also want to get these things on track with the community. It is so great that you are rocking these changes and I'm so proud of what you are doing so I don't want to dismay you, but really I think the next release has to be really on track with the community and we should coordinate it, push it out through the sourceforge system we have in place, and push the press release globally. Without these procedures, honestly, it is not very likely that others will help on development nor use your work. So, lets talk some more and sort these things out. Jon -- Jon Phillips San Francisco, CA USA PH 510.499.0894 jon@...235... http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: rejon@...896... IRC: rejon@...897... Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org)