Considerations of a first time user - ideas for a roadmap

[gggeek]

Hello all.

I just tried to install Xinc - for the 1st time -  as part of an evaluation process.
My need is to find a suitable CI-server to integrate into a "forge" site which hosts plugins for a popular CMS. The idea is to allow every plugin writer to be able t submit a "build" job that would package his extension. The core of the building itself is already done via pake scripts.
Being a php hacker, I hoped to find a good solution which I could extend/fix if needed.

I must admit to getting it all wrong from the start, as I did not install by Pear but tried a manual install (on windows).

As you probably would have told me has I asked before: never do that!
It took me 4 hours of patching to get the thing almost working (and it's still not functional).

I am sure there must have been valid technical reasons for relying on Pear for the installation part of the app, but there is more than my dislike for pear which has me worried: it is the tendency of Xinc to spread itself all over the server, instead of running as most other php apps do (ie. self-contained in a single directory). As I run on windows, spreading all over the place makes little sense - there is no /etc or /init.d here to hold config files and init scripts. And even when running on unix, this makes it hard to install 2 xinc versions side by side. Finally, it depends on too many prerequisistes for working properly: apache, mod_rewrite... what if I want to run it on Nginx?

If you compare this to jenkins, the most widespread CI server out there, you clearly see that Jenkins took the opposite approach: no dependencies, no messing with the system. Drop it in a folder, run it. (Jenkins can actually install itself as a windows service, but you do that from the admin console).

Summarizing, I'd love to see Xinc ditch its dependency on pear, remove as many as possible of its dependencies/prerequisites and be installable via a setup wizard (via running the index.php file the 1st time after download and unzip - just like eg. phpmyadmin. moodle or ezpublish do). Also to resemble more other well known php applications, to make the learning curve less steep for newcomers.

A random list of things which could imho be improved:
1. if an installation script really has to be used, it should be runnable from plain command line, not only when executed from pear installer
2. rename handler.php to index.php
3. make the usage of mod_rewrite recommended but not mandatory
4. make the usage of a dedicated vhost config file optional. ditch usage of auto_prepend php files
3+4. the app should be usable when dumped inside var/www, without symlinking or other
5. don't assume php class autoloading is set up properly, at least when running index.php or install.php
6. make index.php run a setup wizard the 1st time it is run, which checks requirements and does the rest of the stuff
7. naming a cli script xinc.php same as a class definition file Xinc.php is not a good idea. On windows, having "." in include_path before the path to Xinc results in a loop
8. don't force windows users to use batch files. I normally run php files directly on the command line
9. don't duplicate code: xinc and xinc.php do the same. "xinc" should be a shell script in the same vein that xinc.bat is
10. allow inclusion of a custom config. file (php) as 1st thing from both web controller and cli scripts, to allow proper environment setup
11. don't force display_errors off. It's a good idea for prod servers, not for dev servers
12. class Ini.php: in __construct you miss a mkdir call before touch
13. pear classes throw a lot of warnings in the age of php5, forcing to lower the level of error_reporting. It seems to only be used rarely in Xinc. maybe it can be avoided completely?
14. provide a gui or cli script to create new jobs on demand (at least en empty job skeleton file)

Last but not least:
- what about moving the project to github to facilitate loose collaboration?
- what about using Composer to handle dependencies/installation?

Bye
Gaetano

[Alexander Opitz]

Hi Gaetano,

thanks for your interest in Xinc.

The project was a very long time dead and I startet to reactivate it last year. But I don't have so much time and since the birth of my child Helena the time is dropping.

As the project was startetd, PHP5 wasn't out in the wild and the project was more oriented for PHP developers, that why the nobody needed the features that you like to have. Nobody will set up xinc to manage his webspace like phpMyAdmin. We also have not realy more dependencies as phing have and Xinc without phing is a bit useless (at this point yet). Also why should I implement features which are already implemented in a pear package?

And some of your wanted features are already in planing, but why I should have a cli or website configurator when the whole thing doesn't work yet like it should? There are to much outstanding things to resolve before (like cleaning up codebase to a better coding standard).

Why it isn't on github? Cause Xinc has no git plugin till yet, so it can't selftest as it can do with svn support.

So, all in all, the pear dependency won't change, the useability for managing projects will change but not before a 3.0 version and that number isn't planned yet.

For the ini problem you already filled up an bug report and I will fix it for the 2.2 release, after finishing the svn transition.

Greetings
Alexander//

[Gaetano Giunta]

Alexander Opitz wrote:

Hi Gaetano,

thanks for your interest in Xinc.

The project was a very long time dead and I started to reactivate it last year. But I don't have so much time and since the birth of my child Helena the time is dropping.

As the project was startetd, PHP5 wasn't out in the wild and the project was more oriented for PHP developers, that why the nobody needed the features that you like to have. Nobody will set up xinc to manage his webspace like phpMyAdmin. We also have not realy more dependencies as phing have and Xinc without phing is a bit useless (at this point yet). Also why should I implement features which are already implemented in a pear package?

Well, one guy at least wants to use Xinc with 100% custom tasks: me It's not useless to me without Phing.
And I'm a developer, but still like to find tools which are easy to install and that behave more like self-contained webapps than like they need a dedicated server to be installed
Also, I'm not asking to reimplement a lot of features which already exist in pear - as far as I could see, you are not using many fatures of pear.

And some of your wanted features are already in planing, but why I should have a cli or website configurator when the whole thing doesn't work yet like it should? There are to much outstanding things to resolve before (like cleaning up codebase to a better coding standard).

You decide the order of features, of course, but clearing up codebase to a better coding standard is low on my list, as user of the tool :-)

Why it isn't on github? Cause Xinc has no git plugin till yet, so it can't selftest as it can do with svn support.

Just add support for Pake tasks then. It has git support.
I also think that Phing has git tasks.

That might be more useful to do rtight now to try to get more developers onboard than the other things mentioned...

--
You received this message because you are subscribed to the Google Groups "Xinc Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/xinc/-/290hjvSeveYJ.
To post to this group, send email to xi...@googlegroups.com.
To unsubscribe from this group, send email to xinc+uns...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/xinc?hl=en.

[gggeek]

On Friday, June 1, 2012 5:23:45 PM UTC+2, gggeek wrote:

Alexander Opitz wrote:

Hi Gaetano,

thanks for your interest in Xinc.

The project was a very long time dead and I started to reactivate it last year. But I don't have so much time and since the birth of my child Helena the time is dropping.

As the project was startetd, PHP5 wasn't out in the wild and the project was more oriented for PHP developers, that why the nobody needed the features that you like to have. Nobody will set up xinc to manage his webspace like phpMyAdmin. We also have not realy more dependencies as phing have and Xinc without phing is a bit useless (at this point yet). Also why should I implement features which are already implemented in a pear package?

Well, one guy at least wants to use Xinc with 100% custom tasks: me It's not useless to me without Phing.
And I'm a developer, but still like to find tools which are easy to install and that behave more like self-contained webapps than like they need a dedicated server to be installed
Also, I'm not asking to reimplement a lot of features which already exist in pear - as far as I could see, you are not using many fatures of pear.

And some of your wanted features are already in planing, but why I should have a cli or website configurator when the whole thing doesn't work yet like it should? There are to much outstanding things to resolve before (like cleaning up codebase to a better coding standard).

You decide the order of features, of course, but clearing up codebase to a better coding standard is low on my list, as user of the tool :-)

Why it isn't on github? Cause Xinc has no git plugin till yet, so it can't selftest as it can do with svn support.

Just add support for Pake tasks then. It has git support.
I also think that Phing has git tasks.

That might be more useful to do rtight now to try to get more developers onboard than the other things mentioned...

Just in case this was not clear: I could contribute a little bit
 

To unsubscribe from this group, send email to xinc+unsubscribe@googlegroups.com.

[Alexander Opitz]

Hi,

Well, one guy at least wants to use Xinc with 100% custom tasks: me It's not useless to me without Phing.

welcome, you are the second one yet to me known. But that direction isn't the main one yet so it isn't done.
 

And I'm a developer, but still like to find tools which are easy to install and that behave more like self-contained webapps than like they need a dedicated server to be installed

So every package should include all packages they depend on?
 

Also, I'm not asking to reimplement a lot of features which already exist in pear - as far as I could see, you are not using many fatures of pear.

So how you want to remove the dependancies?
 

You decide the order of features, of course, but clearing up codebase to a better coding standard is low on my list, as user of the tool :-)

Why should I add features if I know that I need to rewrite that code? That's something typo3 tried to do, adding features and cleaning code base. But it ended up in splitting the project in two products and in holding back a feature plan for product one. But as I'm the only developer at the moment on this project, why I should do this?

Just add support for Pake tasks then. It has git support.
I also think that Phing has git tasks.

Phing hast git tasks, but that doesn't help as Xinc hasn't git support in the modification sets.
 

That might be more useful to do rtight now to try to get more developers onboard than the other things mentioned...

Maybe we can get new developers, maybe not, something I'll decide after releasing v2.2 (with git support).

Greetings Alexander//

[Gaetano Giunta]

Alexander Opitz wrote:

Hi,

Well, one guy at least wants to use Xinc with 100% custom tasks: me It's not useless to me without Phing.

welcome, you are the second one yet to me known.

:-)

But that direction isn't the main one yet so it isn't done.
 

And I'm a developer, but still like to find tools which are easy to install and that behave more like self-contained webapps than like they need a dedicated server to be installed

So every package should include all packages they depend on?

About dependency management: I think that Pear took the same approach as Linux distributions, while Composer took the OSX approach.

The problem with Pear, from my pov, is that it will by default install one and only one version of every php package.
So if I want to use Pear to install 2 instances of Xinc, I can not (actually I think I can, but you have to jump through hoops to get it working).
And if I want to install Xinc which eg. depends on PhpUnit 3.5, and MegaFoo which depends on PhpUnit 3.6, I can not.

There are of course advantages to a centralized package repository, especially when you use it for managing libraries rather than apps (you can update the library only once if there is a critical security fix; also having only 1 copy of each library is good for APC and other opcode caches).

But reality has shown that web apps evolve too quickly for that model. In fact it is the app I want to install which should dictate which version of dependency X I need, not the opposite.

I think the best of both worlds is obtained not by bundling every dependency with every app, but having a smarter package manager:
- you download the app
- you run app installer (the package-manager code, can be part of app or a standalone tool)
- if dependencies are on your hdd already somewhere, you just tell where your "main library" dir to package manager
- otherwise it downloads the dependencies and installs them. By default dependencies are installed within the app directory, but you can instruct p.m. to save them elsewhere

With eZ Publish (the project I am involved with), to avoid setup hassles to the end user, we actually do bundle in the tarball the complete Zeta Components. This makes the zip quite big, but it follows the "needed libs are bundled by default, if end user wants to have them shared, he can configure it later" principle.

I am not sure if Composer is good enough or even if if follows this approach. But Pear does not seem to be very fashionable anymore, esp. with Pyrum never having taken off...

 

Also, I'm not asking to reimplement a lot of features which already exist in pear - as far as I could see, you are not using many fatures of pear.

So how you want to remove the dependancies?

In the case of using Pear to store an ini file, it's simple: just use a config.php file stored within Xinc itself.
In the case of using Pear to run your post-download script, it also seems easy, as the whole logic is within the custom script, not within Pear.
The only thing that you'd miss, (but of course I might be wrong, I only looked at the Xinc codebase for a little time) is the automatic download and install of phpunit and such tools - note that you would not be preventing users to use Pear to download Phpunit, only not forcing him.

 

You decide the order of features, of course, but clearing up codebase to a better coding standard is low on my list, as user of the tool :-)

Why should I add features if I know that I need to rewrite that code?

Makes sense

That's something typo3 tried to do, adding features and cleaning code base. But it ended up in splitting the project in two products and in holding back a feature plan for product one. But as I'm the only developer at the moment on this project, why I should do this?

Just add support for Pake tasks then. It has git support.
I also think that Phing has git tasks.

Phing hast git tasks, but that doesn't help as Xinc hasn't git support in the modification sets.
 

That might be more useful to do right now to try to get more developers onboard than the other things mentioned...

Maybe we can get new developers, maybe not, something I'll decide after releasing v2.2 (with git support).

Ok

Greetings Alexander//

--
You received this message because you are subscribed to the Google Groups "Xinc Development" group.

[Alexander Opitz]

Hi,

About dependency management: I think that Pear took the same approach as Linux distributions, while Composer took the OSX approach.

The problem with Pear, from my pov, is that it will by default install one and only one version of every php package.
So if I want to use Pear to install 2 instances of Xinc, I can not (actually I think I can, but you have to jump through hoops to get it working).
And if I want to install Xinc which eg. depends on PhpUnit 3.5, and MegaFoo which depends on PhpUnit 3.6, I can not.

That may be a problem, but I didn't had this yet. :)
 

There are of course advantages to a centralized package repository, especially when you use it for managing libraries rather than apps (you can update the library only once if there is a critical security fix; also having only 1 copy of each library is good for APC and other opcode caches).

Especially the security fix problem is nice, also software fixes. I don't need to manage them in every package, this tooks to much time. And most web apps then forget to update their third party packages or the third party packages are to old to get your own code to work inside this web app and so on. :-(
 

But reality has shown that web apps evolve too quickly for that model. In fact it is the app I want to install which should dictate which version of dependency X I need, not the opposite.

The web apps are mostly not written cleanly enough for that model. ;)
 

I think the best of both worlds is obtained not by bundling every dependency with every app, but having a smarter package manager:
- you download the app
- you run app installer (the package-manager code, can be part of app or a standalone tool)
- if dependencies are on your hdd already somewhere, you just tell where your "main library" dir to package manager
- otherwise it downloads the dependencies and installs them. By default dependencies are installed within the app directory, but you can instruct p.m. to save them elsewhere

That's something that someone needs to write.
 

With eZ Publish (the project I am involved with), to avoid setup hassles to the end user, we actually do bundle in the tarball the complete Zeta Components. This makes the zip quite big, but it follows the "needed libs are bundled by default, if end user wants to have them shared, he can configure it later" principle.

For Xinc you can decide to use the pear package or the install package, where you can do your own stuff. But as it isn't lovely managed it doesn't have its own libs directory where you can install your libs like you want.
 

I am not sure if Composer is good enough or even if if follows this approach. But Pear does not seem to be very fashionable anymore, esp. with Pyrum never having taken off...

Do you mean Pirum? Thats only a pear channel server manager. Composer is a approach to fix problems of the dependencies, but I hadn't time yet to investigate what should be done for this. But Pirum seems to handle it since version 1.1.0.

Looked shortly into composer ... now I'm confused. :-)

In the case of using Pear to store an ini file, it's simple: just use a config.php file stored within Xinc itself.
In the case of using Pear to run your post-download script, it also seems easy, as the whole logic is within the custom script, not within Pear.
The only thing that you'd miss, (but of course I might be wrong, I only looked at the Xinc codebase for a little time) is the automatic download and install of phpunit and such tools - note that you would not be preventing users to use Pear to download Phpunit, only not forcing him.

As PHPUnit is optional, I do not force someone to download it with pear. Pear is used for installation, update management, dependency checking (but most packages are optional and the phing dependency will also change from required to optional in the future). And you cann use the install package if you don't like pear package management. (There is pear as package management, as ground functionality system, as coding standard and so on).

Greetings Alexander//