I am open to changes - including project name

-- PeterMasiar - 21 May 2003

If you'd like the Unix based TWikiUnixInstaller (writes the config for Apache, configures authentication - including LDAP, simplifies creation of new webs, enforces correct permissions, etc) I wrote customised for this I'd be willing to make the changes. It's worth noting that the installer uses a slightly different directory structure from a standard TWiki, using symlinks to make the system function correctly. The changes in structure whilst having clear and present benefits to users who've used this approach haven't ever been deemed sufficiently useful by the CoreTeam (*) and as a result leave the user with a slightly non-standard setup.

(*) This might be due to insufficient clarity of explanation (or it could just be plain old differences of opinion)

Specifically the set up I use implements the DataAndCodeSeparation I've spoken about many a time, and used to implement a distributed Wiki server. These days I also use it for auto-pdf'ing every page on our Twiki server, and have a static "public" facing version as well. (along with a downloadable tar ball for off line browsing)

It'd be nice to integrate these with a standard distribution, but based on previous discussions the code & data separation would prevent this.

-- MichaelSparks - 22 May 2003

Good. I'll definitely will try it and if it work - so better to me and less work! Thank you Michael!

-- PeterMasiar - 22 May 2003

If you want more value add (admittedly in exchange for more work), I'd also suggest that you try incorporating PeterNixon's MegaTWiki enhancements.

If all goes well we could then fold in the other bits from BeijingRelease. RcsLite is modular, and I guess the MorePluginsHooks changes are modular as well. The hard bit will be the InternationalisationEnhancements but RichardDonkin is always amenable, responsive and practical so I am confident that any problems you'd face could be quickly and reliably addressed.

(MegaTWiki-specific conversation moved to MegaTWiki) -- WillNorris - 13 Sep 2004

-- MartinCleaver - 24 May 2003

It is a charecteristic of a poor design that it is unmanageable. This and other threads are highlighting that Twiki has grown beyond managebility and needs a Damoclean rationalization. I hope my upcoming Object Oriented redesign goes towards that. I'm going to discuss installation and upgrading but also how to structure a "next generation" TWiki so as to make the process simpler and more robust.

This is important as the acceptability of Twiki is not just in its functionality as a running application but whether or not users cna overcome that first hurdle - installation. I'm going to propose and outline the use of RedHat's RPM. I'm aware there are other package managers - RPM is the one I'm familiar with.

But lets step back and see how many of the classic textbook symptoms of poor design are extant here so we know what we have to address strategically rather than just do tactical patches:

• Unmanageable
• Unsatisfactory and unproductive
• Unreliable
• Inflexible and difficult to maintain and extend
• Inefficient

So why do I mention these, what do the "classical textbooks" say about them? What are the characteristics to look for?

• Unmanageable
  • "Code before document" and "Code before design"
  • Large gaps between milestones
  • Fuzzy definition of the milestones
  • Poor response to user requests
  • Problems with installation and upgrade

• Unsatisfactory and unproductive
  • "Software engineering" has little discipline
    • Open Source highlights this
  • Lack of formal PM methods

• Unreliable
  • Lack of formal test plan from the spec/design
  • End users find many bugs & operational problems

• Inflexible and difficult ot maintain and extend
  • Problems don't have clearly identifiable source in the code
  • Lack of formal spec to define what it should and should not do
  • Lack of integration of fixes into core or modules

• Inefficient
  • Each relase gets slower
  • Lack of instumentation by designers, coders
  • Lack of consideration of useability and ergonmics of the UI

All I've done here is condense and precis what you can find in many threads in Codev and Support. Don't blame for summarizing I'm only the piano playermessenger!

The problem with installation and in particular, upgrade, is many-faceted, but if I had to use one tag I'd say it revolves around a confusion between code and data.

What gets installed? What gets configured? What gets upgraded? What does the "upgrade" amount to - over-writing?   - merging?

TWiki is an interpreter built on top of an interpreter. Fine, until you forget that. Then the confusion sets in. Where is the code and where is the data? You think the code is in twiki/bin and twiki/lib? WRONG WRONG WRONG

The code is in every topic and every web and every part of every skin and plug-in and it's a ball of string that the cats and rats and spiders have been at.

Lets take that in parts.

• Data is transformed by code according to the parameters into something that gets dislayed.
  • But the parameters are embedded in the data and the data interacts with other data - in the plug-ins and in the skins, as well as the other topics.

• __The skins are highly irregular__
  More on that in a moment.

• There is a high degree of coupling - that is the rule "each thing does one thing and only one thing and no side effects" is broken. Its broken in the core code for a variety of reasons and its broken in practice.
  • Example: In pub/TWiki/TwikiDocGraphics there are a pile of neat icons. However some skins such as "Hobbes" use their own. This means there is not a single space where you can adjust an icon for "look and feel". This is a classic case of STAMP or COPY coupling.
• Cohesion appears Functional but the thread of execution shows that it is at best Procedural but is mostly Logical or Coincidental. The flow of control bounces around between the modules and makes it clear that the model for coding is not concerned with the flow of data.

So we need discipline and documentation. The two things that programmers hate. Perhaps that's why I gave up coding to become a PM and why I'm so good at it.

The second set of problems arises out of confusion of functionality.

I've written at length about the evils of in-band access control. This is a prima-facie example of coupling. The data affects the data. Access control should be orthogonal to the data. Look at an ordinary file system.

The problem is aggravated by having Settings embeded in the data. This also affect performance and is one of the major problems with upgrades. Over-writing the Preferences topic over-writes the preferences, many of which may have been customized. But the upgrade may introduce new settings. UNIX and Windows address this in differnet ways.

• Windows has a central registry as a DB.
  • Adding new settings is simple - just add them
  • Some settings MUST take the new value - over-write them
  • Some require a user decision. Since upgrades are interactive, this is OK

• UNIX/Linux has files - see /etc/--applicationname--
  • RPM has the ability to run scripts to do specifics of the upgrade

Let me give a RPM example here. Suppose we have a database for settings upgrade such as described in DatabaseForPreferences by myself and MichaelRausch in PrefsDotPm. This is going to involve

• New code in Prefs.pm
• Converting all topics to have their preference settings out of band.

So the new release has a RPM script that

1. Keeps track of the current release and dependencies
   • This may include things from CPAN, Perl libraries, and such like
2. Installs the new Prefs.pm
3. Parses every topic and extracts the settings, puts them in the per-topic database
4. Replaces the "Set" statements with a "%SET{key}%" statement so the topic displays the value from the DB
5. Installs the code to edit preferences
6. Adds "buttons" to the base skin to allow users to update preferences.

However, poor skin definition and design makes that last point problematic.

Now what about an upgrade RPM

1. Makes sure that the previously required upgrade has been applied
2. Adds the new settings to the relevant per-topic databases
   • This may be a bit involved if, for example, a new setting is to be added to every user's home page, but it is within the capability of the scripts.
3. Produces a list of settings that may need to be merged by hand

Bingo. So lets go with RPM. All Linux sites have it and the source is available for the platforms that don't normally make use of it.

A Bit of History and a UNIX vs Windows perspective

This is about centralization vs distribution. Both UNIX and Windows do both, and both have been through phases of confusion.

• UNIX/Linux puts all the binaries in "one place". OK the one place is /bin /usr/bin /sbin /usr/sbin
• Windows puts it binaries in many places - c:/Windows/ c:/Windows/system32 and c:/My Programs/whatever

• UNIX puts its configuration in a set of files in an application specific directory under /etc
• Windows has a centralized registry

It didn't use to be so. Linux saw the "/etc Purification Project" that removed binaries and non-config executables from /etc. Even so, there are still many scripts in /etc. Windows-3.1 had many application specific INI files, but they were not all under one grouping.

So what goes in twiki/pub ?

Attachements, obviously.

But what about things that aren't attachements such as logos, and the graphics that go with skins?

This is incompletley specified.

So what about skins?

I've complained about skins. Many skin writers DON'T GET IT. Perhaps those that do are geniuses and the original idea was too obscure.

Skins are like subroutines, or macros if you prefer, macros that do a specialized form of include.

Look at the code that does the parsing of a skin. If we ignore the undocumented per-web skins then it looks for

• function.skinname.tmpl

Where function is all of view, edit, attach and so on. If it doesn't find that it looks for

• function.tmpl

so that Twiki doesn't break.

So if the skin designer only supplies view then everything else looks like the - as ArthurClemens says in TooUglyForNonTechnicalUsers - ugly out-of-the-box version.

But what many skin designers DON'T GET is that skins are subroutines. A base

• twiki.skinname.tmpl

should contain the (macro-)definitions that get re-used in all the other templates. This makes life easy. If you don't have attach.skinname.tmpl then TWiki will access attach.tmpl. It sees the INCLUDE statement for "twiki" and reads in - guess what? - twiki.skinname.tmpl. Twiki has done most of the work for you -- IF you set up twiki.skinname.tmpl and don't make the individual templates do all the work.

That's about documentation, even if it is reading and understanding the code, now lets look at the design.

this is excellent skin information that should be massaged into the docs -- WillNorris - 13 Sep 2004

The design aspect of skins has a short coming in that the skins have to define everything that TWiki emits. There is nothing to make sure the basics of correct HTML are enforced.

What do I mean by that? Let me take an example from my office white-board where I'm working on the OO version of TWiki to offer an alternative.

All the CGIs make use of the CGI module to parse the URL and extract the arguments. But that's all. The CGI module can do other things as well:

• Debugging
• Caching
• Redirection
• Cookies and session handling
• Outputting headers ...
  • ... with the language encoding
  • ... with HTTP_EQUIV
  • ... with the "title"
  • ... with the MIME type
  • ... with META information
  • ... with style information
  • ... with javascript
• Closing

Really a template is specifying the body. The header and everything up to and including the <body> -- if this is HTML -- is mandatory and should not be up to the vagary of the skin desginer. TWiki should manage that, as well as the tail end. The CGI module has this capability.

Yes, the skin designers should have the option of over-riding defaults:

• Does the title read "%TOPIC% < %WEB% < TWiki" or something else?
• Is the body HTML, plaintext or what?
• What style information should be emmitted?
• What, if any, arguments should there be to the <body> that over-ride the default of setting the text background color?

But failing that, a correct header using system specified defaults should be emmited, regardless of that the skin designer does. Outputing a correct and correctly formatted header is too important to be left to the whims of the skin designer when the computer can do the work.

It also simplifies a lot of things. Like upgrading. Skins are now less of a burden and more modular.

See:

• http://www.perl.com/pub/a/2001/06/05/cgi.html
• http://search.cpan.org/author/JHI/perl-5.8.0/lib/CGI.pm

-- AntonAylward - 28 May 2003

Bingo. So lets go with RPM. All Linux sites have it and the source is available for the platforms that don't normally make use of it.

Summarising the conversation that resulted from this: Despite the wording the suggestion was to make available RPMs for systems that use RPMs in addition to the current distribution method. I've deleted my comments based on the suprise of the apparent suggestion to make RPM the only distribution method. ( that discussion is here )

-- MichaelSparks - 30 May 2003

If somebody will create out-of-the box RPM-based Twiki installer to solve upgrade to maybe 40% of Twiki admins - thats great and nothing to get bananas about . I heard there are package converters (I am not white-bearder guru ). Windows users can either install manually as they do now, ask somebody to create installer, or switch to Linux - it's free.

Of course we need to think about minor distributions (and maybe debian will be the major one, not RPM), but why to slow progress waiting to all 100% to agree? I do not agree with Anton 100%, but why not try the code? If his OO Twiki will be fast, flexible, usable and easy to install/upgrade, maybe it will invite more developers to port his solution to all this other platforms Michael is concerned. And if it does not - well too bad.

Of course, we need to think about portability and try to compromise some to make these other ports easier, but not for the price waiting everybody to agree. We know that installing Twiki on IIS is not easy, but so what? I prefer scarce development resources be focused on ie. fixing CommentPlugin locking issue, new default skin, and easier upgrade. If Next Twiki will not run at all at IIS - I'll be sorry for guys who are stuck, and will hope some gurus will solve that, but it will not prevent me from upgrading.

We can easily have both: stable Twiki, and some major improvement in Next Twiki. If it will be disruptive - well you have choice: switch, or port, or stay on stable version and improve it slowly and incrementally.

Michael, your own installer was not accepted into core. Will it solve 90% of the installation problems for 60% users? If yes, why not to do that?

-- PeterMasiar - 29 May 2003

Peter

> Michael, your own installer was not accepted into core. Will it solve 90% of the installation problems for 60% users? If yes, why not to do that?

I would've thought it would yes. I released for that reason after all!

-- MichaelSparks - 29 May 2003

So we're agreed. The issue isn't the technology, the people to build things, it acceptance into the core.

-- AntonAylward - 29 May 2003

Could we please refrain from exhaustive point-by-point rebuttals and counter-rebuttals unless it actually builds a better whatever-it-is? It is good that Michael pointed out RPM is a limited solution for a partial segment of the twiki community. Likewise Anton reiterating that he was only addressing the tools he could speak from experience on needed to be said.

-- MattWilkie - 29 May 2003

Most important to say that:

• TWiki is Perl, many libs are CPAN, CPAN is standard way of distributing Perl, CPAN works on both Windows and Linux and will be made to work anywhere that Perl is made to work. Futhermore when a Perl admin is looking for apps CPAN is a most likely first stop.

I think therefore CPAN installer is the way to go.

-- MartinCleaver - 29 May 2003

Good point, Martin. 100% I'm kicking myself for not thinking of that.

I'm only a CPAN user, I've never built a package. Can someone tell me how it would:

• Let the user determine where to install ...
  • The webs
  • The library
  • The CGI scripts
• Update TWiki.cfg accordingly
• Update the web server config files
• Create an appropriate userID
• Set up ownership and access

• Download from a TWiki mirror rather than a CPAN mirror.

I've seen CPAN ask me if I want to run tests and choose which site to download from, but I'm not sure how it does its scripting.

If this is a GO then we also need to convert the plug-ins and skins to such packages.

-- AntonAylward - 30 May 2003

One small note on CPAN modules: on most hosted domains that even allow extra perl modules, one needs to request support to install them. I don't know if CPAN installer can be configured to install TWiki components in some non-default, more accessible place. If not, it would be very inconvient to have to get support simply to install a skin. Once again, I'm out of my league in this conversation so my apologies if this is a non-concern. Just wanted to put in a voice for us hosted twikizens.

BTW, I wondering if this topic might need to be refractored into various topics on various aspects of designing TimDistro. To start, perhaps this thread on installation options could be moved to ImprovedInstallation. (I thought there was already topic along these lines but can't seem to find it.)

Perhaps we could set up some headings within this topic like:

• Skin
• Installation
• Pre-installed add-ons.
• Default webs (opps... I guess that's "zones" if Peter gets his druthers. )
• Etc.

... and then spin these off to new topics if they get big enough. Since PeterMasiar started up this topic, I would invite him to do some serious refractoring and restructuring if he is so inclined. I think it could really move the conversation forward at this juncture.

-- LynnwoodBrown - 30 May 2003

CPAN modules can be a pain to install for new users of TWiki, because the default CPAN setup requires root, and because of firewall issues. Modules that require compilation of C code in XS extensions are also sometimes difficult to get compiled cleanly. Going the CPAN route is a reasonable decision, but it needs to be made with full awareness of the consequences. Frequently there is no 'Perl administrator', just an overloaded Unix administrator for whom making even httpd.conf changes can take weeks (from my experience). See CpanPerlModulesRequirement for more discussion.

So, any use of CPAN modules should IMO bring in these modules to the TWiki tree, in a suitable sub-tree, so that they are always pre-installed as part of TWiki, and should also avoid any that rely on C code. This is already done for RcsLite's CPAN:Algorithm::Diff. This would bypass the installation hassles completely, and the only overhead would be to occasionally update the TWiki instance of the CPAN module as module bugs are fixed.

-- RichardDonkin - 30 May 2003

Richard, I think you're missing the point in your initial coment, though you do get back to the core issue.

Martin was talking of using the CPAN installer mechanism, not the CPAN archive. He was talking of using it to do the unpacking and instalation of TWiki. As you say, all the "bits" would have to be in the TWiki tree.

My questions are relevant to this:

• Can the CPAN code be pointed to any other source than the CPAN mirrors, for example a local filesystem?
• Can the CPAN source be told to unpack into a location other than the system wide library?

-- AntonAylward - 30 May 2003

CPAN the installer (actually the CPAN shell) is probably quite hard to use without CPAN the archive - they are meant to work together. You can point CPAN installer at offline copies of the CPAN archive, so it probably can work on a completely different 'archive' - however this seems like a lot of overhead since you need to generate various files to put together the archive. I don't think the CPAN installer is really the right place to start, which is probably why I assumed this was about using more CPAN modules (which Martin has talked about quite a lot).

You can get CPAN installer to unpack into a local directory, but it's not that easy - many CPAN users don't know how to do this, and it involves typing a few commands into the shell.

However, CPAN:CPAN is also a module, not just an installer shell, so it should be possible to script our own installer while using the shell. CPAN:CPANPLUS may be a better starting point but it's not part of the Perl core until Perl 5.10.

Anyway, if we are going to do this we need to be clear on what the goals are - do we require the installer to grab modules from the CPAN archive, or just from a separate TWiki archive, perhaps a ZIPped directory tree?

There are quite a few other installer/packaging technologies we should look at - I'm not convinced that CPAN is the best place to start, though it may be part of the solution.

-- RichardDonkin - 30 May 2003

Just to remind everyone, the Zinger with CPAN:CPAN::Shell is that we are all running perl anyway. This was point MartinCleaver made. It trumped my discussion about platform specific installers.

-- AntonAylward - 30 May 2003

The zinger with CPAN is that it's quite hard to use, particularly on Windows - the wrong HOME or TEMP variable can break things, as can firewalls and so on. I'd recommend looking at CPAN:PAR - this lets you bundle a whole set of Perl scripts and modules into a single archive file, and run from the archive file without even unpacking it. You can even generate a runnable .exe corresponding to this file - e.g. twiki.exe for a given platform. Very impressive - there's an example of installing the rather complex and CPAN-heavy SlashCode in just 6 lines in this PAR Tutorial.

-- RichardDonkin - 01 Jun 2003

So lets see if I understand you correctly, Richard:

• If the firewall doens't permit the FTP:: or the LWP:: module of Perl to performa a FTP or HTTP to download from a CPAN mirror, CPAN is "broken" for the user.
  Surely this applies for *NIX as well, and has nothing to do with Windows and everything to do with the corporate firewall policy. If corporate policy forbids downloading software that isn't authorized then doing so may result in a reprimand. Continued violation of corporate policy may result in dismissal. This isn't a Windows problem.

• Misconfiguration of the users environment can prevent CPAN from operating correctly.
  Yes, even under *NIX I could tell it to download to a non existent directory.
  Just as Windows users can fiddle with the registry and the autoexec.bat to mess up TEMP (or TMP) - BTDT - so to can *NIX users mess with their .profile. This isn't a Windows problem either.

That people can screw things up if they try shouldn't be an impediment to using a tool that is otherwise quite capable. I can injure myelf with my coffee cup, my keyboard, my plastic fork or my Camel book if I'm stupid enough. Enough people injure themseleves with automobiles, power-tools and household objects. That doens't stop their use.

I'm perterbued to hear that you can package things into an exe. Pulling something like that thourough the firewall is a security risk Doing that can get a lot of people in trouble as violating corporate security policy.

-- AntonAylward - 02 Jun 2003

This has all been covered a lot elsewhere - e.g. the firewall issue is that it's hard to get CPAN the installer working at all behind some firewalls, nothing to do with policy.

Please have a look at WindowsInstallCookbook, particularly the various updates done over the last year, and the many TWiki.org Support web pages on installing TWiki on Windows, which is the only common platform where use of CPAN is always required. There are many practical issues encountered by TWiki users that an easier installer tool should 'engineer out' - WindowsApacheUsesWrongPerl is a recent one, some others are AttachmentFails and InstallDigestSHA1Fails. Issues on Unix/Linux are not so frequent but are still perplexing at times.

I thought the idea was to come up with easier ways to do the installation, so as someone who's done a large amount of user support for people trying to install on Unix and Windows, I was pointing out that CPAN (the installer) is not a good place to start. While I agree in general with your point about 'sharp tools can cut you' (I'm a Unix/Linux user by preference), that's not the way to ensure a quick and easy installation of TimDistro - people still have real problems installing TWiki on Windows, even with the cookbook.

It's better to just bundle CPAN modules within the TWiki distribution, which also guards against interesting bugs introduced in certain modules (viz. CPAN:CGI bug with attachments recently). I was pointing towards CPAN:PAR because it might be a good way to bundle TWiki together with certain modules - the .exe is an optional extra but would make it very easy to get TWiki installed on Windows.

What might be helpful is a DocumentMode page that identifies the requirements and non-requirements for a new installer, as part of TimDistro.

-- RichardDonkin - 02 Jun 2003

Realising that there was nothing else I could say, I contacted Elaine HFB Ashton (elaine@chaosPLEASENOSPAM.wustl.edu) - a leading authority and a main contact point for CPAN - referring her to this page and asking her:

> Are we wrong to be pushing for CPAN to be used this way? Is there an article
> or process you can point to that might help resolve our issue?

She just replied, saying:

All of the arguments I can see from scanning the page stem from a lack of reading the documentation. CPAN.pm comes with every perl distribution these days and each individual user can set up their own configuration and install libraries for the system or for themselves in a private directory. CPAN.pm can also install modules from local repositories. Whatever the CPAN FAQ doesn't answer, http://www.cpan.org/authors/id/H/HF/HFB/grok-cpan-1.01.pdf possibly will along with the CPAN.pm documentation.

Perhaps, Richard, you can give a concise list of examples of the issues so that you and I can try and work through them. Anything we can't figure by looking at the documentation I'm sure a CPAN expert will help us with.

-- MartinCleaver - 02 Jun 2003

The problem is that CPAN is great for Perl experts, but the average person installing TWiki doesn't fall into that category - see AdminSkillsAssumptions. While it's possible to tell the TWiki administrator to read the CPAN docs this doesn't make for an easy installation! I don't have time to collate the issues - just read the various Support entries mentioning CPAN, many of which I have responded to. I also suggested above that you look at WindowsInstallCookbook, which has a list of updates.

If I was going to write an installer, I wouldn't start with CPAN - there are several other approaches, but CPAN is somewhat hard to use for the average person (e.g. firewall issues, compiler issues, spaces in variable names, etc) so it's much easier to just bundle the modules with TWiki as I've said above. Then it's just a matter of writing a TWikiUnixInstaller to step the user through configuration, permissions, file re-locking and all the other things (as in WindowsInstallCookbook only automated). I really don't understand why you think the CPAN installer is a good starting point, and I can't think of any other ways of re-stating my point.

Your argument quoted from above seems to be just by association that TWiki is Perl, CPAN is standard way to distribute Perl, etc:

• TWiki is Perl, many libs are CPAN, CPAN is standard way of distributing Perl, CPAN works on both Windows and Linux and will be made to work anywhere that Perl is made to work. Futhermore when a Perl admin is looking for apps CPAN is a most likely first stop.

Many web apps actually don't use CPAN to install their code, and some actually bundle the CPAN modules rather than using the CPAN installer. This is because of the detailed issues arising from using CPAN, as seen on the Support web - I suggest you spend some time reading up on these (hint: Google:twiki+cpan+issue where issue is firewall, compilation, temp, home, etc.) One current example of the joys of CPAN installation on Windows is at WindowsApacheUsesWrongPerl, as mentioned above. I'm not sure why I'm repeating myself when you haven't read links provided in my earlier comment, though...

-- RichardDonkin - 03 Jun 2003

If everything does go well I think the admin assumptions and requirements of CPAN are far lower than those of TWiki. Maybe the problem is that the CPAN shell does not give URLs to the right part of the documentation? Furthermore, perhaps the issue with TWiki and CPAN is that we are not pointing the TWiki documentation into the right parts of the CPAN documentation.

I apologise for not looking through the references you gave. I will do that by end of Sunday.

• Only one thing worse than not acknowledging a deadline passed: not resetting it.
• Am killing myself to get studies done at the mo (not enough hours to sleep), so will have to put that task on a backburner. If all goes well, next Sunday. If not, someone else is welcome to complete CommonCpanProblems.

I have nothing against bundling a known good mix of CPAN modules with TWiki, in fact in CpanPerlModulesRequirement I was the person who initially suggested it.

I have passed on Torben's WindowsApacheUsesWrongPerl article to Elaine and asked for a support forum in which CPAN experts can solve TWiki users issues.

• She said there was the newsgroup - and that seems to solve most problems.

Using CPAN:PAR is better solution than writing stuff ourselves. Every time we code something ourselves its more to maintain.

-- MartinCleaver - 03 Jun 2003, 09 June 2003

I am no way expert Linux admin, but installing Kwiki from CPAN took me whole 15 minutes including download. Why Twiki cannot have this kind of installer? To keep unwashed admins out? They will just swith to Kwiki - BTW changing formatting rules is in examples of customizing, and script to upgrade to next version is included. If you do not believe me it's possible, set aside 15 minutes and try yourself.

-- PeterMasiar - 10 Jun 2003

CPAN is usually easy to install and setup (especially these days). i suspect that many of the horror stories relate to rather broken versions of packages that RedHat is notorious for shipping. pure perl cpan modules especially should not present an undue installation hardship for sysadmins or isp's.

i believe the best solution is to ship (whether it's included in core download or make available separately) a sparsely-populated cpan mirror (which MartinCleaver details how to create in CpanPerlModulesRequirement), obviatating internet connectivity and root-level access. the mirror creation can (and should) be automated, requiring only a simple and short script. (integration of the packager's counterpart installer into a TWikiInstaller or a TWikiUpgradeScript is a separate matter)

i think this is the (pure perl) solution elaine was hinting at in her reply to MartinCleaver. obviously, and as discussed above, there are also other packaging mechanisms.

-- WillNorris - 13 Sep 2004

Far be it from me to argue with a man who is about to be battered by yet another hurricane, but the horror stores do not just relate to broken packages. IMHO CPAN installation is an absolute pain is the butt. Some reasons:

1. The best way to do a CPAN install is MCPAN. Unfortunately if you are behind a firewall, this is often not an option.
   • that's why i suggested creating a sparsely-populated local cpan mirror which could be shipped with the distribution, or released separately. i've attached a script to create a local mirror. there's still the issue of which modules to mirror, but that'll be the output of another tool)
2. The next best way is to download the packages and install them yourself. But then you hit the second problem; what if you aren't root?
3. OK, so you can solve it by setting PREFIX. But then you get some wierd. opaque, convoluted directory structure under your install.
   • which is the only option there is, if you want to install additional modules. i'm working on a script which would install these cpan modules locally, under $TWIKIDIR/lib/CPAN/. that's not weird, opaque, or convoluted. besides, when everything is sufficiently automated, administrators won't need to be poking around at the filesystem level, anyway. -- WillNorris - 25 Sep 2004

All the above is designed to frustrate the heck out of an experimenting user. A TWiki install is really pretty trivial; CPAN just makes it more complex than it needs to be.

• a basic stripped twiki install may be pretty trivial; not so when you start adding many plugins and addons
• besides, i'm not actually talking about a twiki install here, i'm referring to support code for modules installation
  • besides besides, once/if TWiki is in its on CPAN-compatabile namespace and all, these same script can be used for a better twiki install as well. this will fall out eventually, but is not my main design prupose. -- WillNorris - 25 Sep 2004

If the CPAN install strategy is so simple, why hasn't anyone built a CPAN install for TWiki as an exemplar?

i'm not going to answer that question; i've got at least half a dozen answers to it, but those answers don't forward discussion or development (and perhaps quite the opposite...)

instead, here's the core of a not-yet-battle-hardened, not-yet-configurable-enough (will need to be able to install to a non-system directory) cpan modules installation script. this combines nicely with conf urllist to install from a local CPAN mirror, as described above

#! /usr/bin/perl -w
use CPAN;
CPAN::Shell->o( conf => prerequisites_policy => 'follow' )
foreach my $module ( @ARGV )  # pass list of modules to install on command line
{
    my $obj = CPAN::Shell->expand( Module => $module ) or warn $!;
    next unless $obj;
    $obj->install; # or warn "Error installing $module\n";
}

-- WillNorris - 25 Sep 2004

The ideal is that TWiki can be successfully installed by following these instructions:

1. Download TWiki20041101_Apache_20.zip (or other appropriate package) and unzip it
2. Put "Include /my/path/twiki.cfg" in your httpd.conf, and restart the apache server
3. Enjoy

I'd rather see us put effort into automating the generation of packages for different targets than trying to build a do-it-all installer.

-- CrawfordCurrie - 14 Sep 2004

that's still requiring root permissions to edit apache setup (nowadays you copy the twiki.conf into /etc/apache/conf or something)

-- SvenDowideit - 14 Sep 2004

• yes, i'm still stuck on the root permissions thing, too. but can't the contents of twiki.conf go into a local .htaccess? -- WillNorris - 25 Sep 2004

For what I see, there are two installation scenarios:

1. Install globally, having root access to install everything that's needed.
   1. Put everything someplace
   2. Modify the http.conf file
   3. Restart apache.
2. Install locally, not having root access but making sure that everything that's needed is installed.
   1. Put everything someplace adequate

I don't see why a simple installer can't do both of them.

-- RafaelAlvarez - 14 Sep 2004

Will - as long as the appropriate Options are set in httpd.conf, I don;t see why not.

-- CrawfordCurrie - 26 Sep 2004

i'm going to refactor this page within a few days, removing a lot of CPAN misconceptions.

-- WillNorris - 07 Oct 2004