Alec Flett wrote:
John Anderson wrote:
I think it makes sense to have an end-user version that is stripped of
all the unnecessary stuff, e.g. unused Python packages, pylint,
pychecker, epydoc tests etc. if it reduces our footprint. Do we have
any idea how much space can be saved by doing this?
I have to agree. In particular, I feel like pylint and epydoc are
really meta-development features - i.e. once you're already a
fully-fledged chandler developer, then you might want to actually use
these tools to improve code.
Further, I don't think a "debug" version is very helpful if the
distinguishing characteristic is that it includes wx symbols. I develop
for chandler every day and have not done a "full" build of wx in
perhaps 3 months. Even when I did all the calendar UI/gradient work I
never needed more than a "make install" build. This is the kind of
development we should be encouraging for chandler, not environments
where people are loading up Visual C++ or gdb.
The distinguishing characteristic of the "debug" version that I find
most useful is the asserts in Chandler, wx, and Python -- in that
order. Last weekend I discovered that if you quit Chandler while
editing a field in the Summary or Sidebar, Chandler crashes. I would
have never discovered that if I weren't running the Debug version.
Today almost nobody runs the debug version -- I suspect mostly because
it's slower. On Windows it's awkward to setup cygwin for most users
just to do a build. On Mac you also have to install the developer
disks, which some people don't want to do. Then you have to wait
forever while the build runs -- or fails like it did over the weekend.
If we make everyone jump over all these hurdles to run the debug
version, even fewer people will run it and we'll miss bugs. Instead, I
think we need to make the debug version easier to run (and not too
slow), not harder to run.
As for footprint, Python itself is 56M? I just looked, and did a
breakdown:
wxPython: 21M
Twisted: 4M
PyICU + ICU: 13M
PyLucene: 4.5M
Total 3rd party libraries in site-packages, plus ICU: 48M
I don't care how cheap disk space is these days, we're starting to seem
like OpenOffice if it takes more than 60M on disk just to run a PIM!
I'm not sure what we can do about this right this moment, but its food
for thought.
Alec
That
said, if possibile, I think the end-user version should be
identical to the developer versions, except for some missing files.
I also think it's useful to have a "debug" version that can be
downloaded, i.e. you don't have to build it. I find a significant
number of bugs with the debug version, so I assume other people will
too -- and building Chandler is too difficult for most people.
John
Heikki Toivonen wrote:
Bug 4743 asks us to add RunChandler scripts to the end user version of
Chandler. This means we also need to include python executable and
RunPython script. We've already added tools directory to the end user
version.
Since it seems the end user version is becoming more and more like the
developer version I think we should again consider dropping the
developer version and just adding all we want in the end user version,
making it the one and only Chandler distribution.
So it seems we need at least:
tools
RunChandler etc
added in the end user distribution.
I think we should also add:
pylint, pychecker, epydoc?
tests?
Note that all of these are needed/used by some of the scripts in tools/.
With the end user version people would have the option of editing
RunChandler to remove -O argument for Python, which would get them a bit
more debugging information than with what comes out of the box.
The only thing people would miss are the debug symbols built into the
components that were native code (C/C++). My opinion is that people who
want this should just build Python etc. themselves, i.e. doing a
Chandler full build.
Going with one distribution per platform would have several advantages:
* Simplify it for the people who come to download Chandler
* Simplify it for developers, less need to guess what build/which
distribution
* Reduce manifest files from 6 to 3 - less work and possibilities of
messing up
* Reduce work needed by Tinderbox clients - Tbox clients cycle faster
* Less space needed on download servers
Opinions?
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
|
