Privatebin: Fatal error problem - include_path='.:/usr/share/php:/usr/share/pear'

[chatq]

hi. i had PrivateBin v .22 and it was working without problem. i wanted to upgrade it for latest fixes and did;
git pull privatebin.
it's not recommended way to update my currently working script? i should delete and git clone privatebin from zero?

i thought git pull would be enough and still thinking so. because both of ways didn't solve this problem. i am copying error message;

[error] PHP Warning: require(~/paste/vendor/symfony/polyfill-mbstring/bootstrap.php): failed to open stream: No such file or directory in ~/paste/vendor/composer/autoload_real.php on line 66

[error] PHP Fatal error: require(): Failed opening required '~/paste/vendor/symfony/polyfill-mbstring/bootstrap.php' (include_path='.:/usr/share/php:/usr/share/pear') in ~/paste/vendor/composer/autoload_real.php on line 66

i'm on debian wheezy and pear is on /usr/share/php/PEAR/ path. not in /usr/share/pear. i wrote right path for the "include_path" in boths /etc/php5/apache2/php.ini and /etc/php5/cli/php.ini config files. and restarted apache. nothing changed.
can you say me this script using cli ini or webserver ini path?

as this problem continued, i did "rm -rf * .*" after took my backups. did git clone privatebin. i had again same problem. so it means to do git pull privatebin wasnt causing the problem for it. also i did same things as on above and other things. nothing solved the error. it shows just white page.

i also tried to give file or dir paths on require $file; and didn't help.

after spent long hours, i fixed the problem by putting // to comment out that 66. line from autoload_real.php to ignore that line. my site works now but im waiting a fix from you or tell me if my solution is enough well ?

fix on line 66:

// require $file;

[elrido]

I start to dislike the composer autoloader: For the development environment I have of course more composer packages installed then just the autoloader, hence the JSON can stay empty for the production version.

This should now be fixed with 5e3db21 and 94691cb. Could you do another git pull and see if this change solves the issue for you?

As soon as we have the current release out of the door I would of course advise to only install the tagged releases and not the master, which can contain breaking changes like this one. On the other hand I am happy that you could help us find and resolve it. ;-)

[rugk]

The vendor dir should not be in the repo at all. It is also correctly ignored in the .gitignorefile. Could you have a look why it was committed?

[elrido]

I did commit that on purpose (778fa6d), because we decided to drop the custom autoloader and use the composer one instead. As we still want to allow easy install by uploading the files into some directory, we need to ship another autoloader.

I added a composer setting, so the custom prefix is not always regenerated when your working with your local composer.

[rugk]

It is really bad practise if you do it in this way. You should always use the composer.json for this.

As we still want to allow easy install by uploading the files into some directory, we need to ship another autoloader.

Why? This is not needed. Just download all files, run composer install ZIP all content and upload it as a "binary" attached to a release on GitHub. This way users still can use PrivateBin by just uploading some files.
Of course if you want the latest bleeding-edge version you have to use composer anyway, but this is recommend for developers only anyway as stable versions should run on servers. So if an advantaged user/dev/Contributor wants a bleeding-edge version, this user can certainly use composer too.

[elrido]

First, as you can see in the commit I referenced above I did indeed do the necessary change in composer.json, too.

Second, I did it exactly as suggested in the composer issue on this topic, so it isn't a bad practice at all.

Third, it is indeed a bad practice if we start to force users of this project to have to start to use composer to use a particular version. What we (and that clearly includes myself as this issue here shows) should rather do is to ensure that the master branch (or whatever we declare as the default branch in the repos settings) is in a working condition, by working on our changes in separate branches or a shared development branch and merging it only when these have been properly tested.

One of the primary goals of this software project from the get-go was always to be very easy to install.

The release archives should be automatically generated by the git archive function. Hence we need to include all necessary code in the repo (even other composer modules if we decide to use such) and keep a well maintained .gitattributes file. This will also keep packaging much easier for other package formats.

[rugk]

Second, I did it exactly as suggested in the composer issue on this topic, so it isn't a bad practice at all.

Well... the comment you linked to answers question, where the user ex licitly says, he wants a working solution and does not "want to change its workflow". Of course the composer maintainers had to give an answer to this, but this does not make it a good practise.

As you might have aloes seen, this FAQ entry is also mentioned. And it is quite clear:

The best practice is to then have all the developers use Composer to install the dependencies. Similarly, the build server, CI, deployment tools etc should be adapted to run Composer as part of their project bootstrapping.

And I think we all agree on this statement.
But I get your point. Not all server admins are devs and want to install composer. So the FAQ entry goes on...

Limit yourself to installing tagged releases (no dev versions), so that you only get zipped installs, and avoid problems with the git "submodules".

This is exactly what I meant, but it is obviously not enough for you.

Now your quotes:

What we (and that clearly includes myself as this issue here shows) should rather do is to ensure that the master branch (or whatever we declare as the default branch in the repos settings) is in a working condition,

So you want another branch. It is just that "master" usually just is the branch for developing and testing, so you can consider "master" to contain nightly versions.

by working on our changes in separate branches or a shared development branch and merging it only when these have been properly tested.

Yeah, of course. However this still does not mean that this branch should be used on a production server. Maybe we could use a "stable" branch for this?

The release archives should be automatically generated by the git archive function.

If that's possible it is of course good. In such a case we could even automate the first idea in some way at least.

Hence we need to include all necessary code in the repo (even other composer modules if we decide to use such

Ah, that's bad. Could not we use a git hook somehow, which just runs composer install?
Or do that build process with Travis-CI?

[elrido]

Lets agree to disagree then.

Contrary to what is stated in above FAQ I actually want to have the history of changing dependencies (and even went to great lengths to cherry pick SJCL commits to keep even the authorship intact). I want this repo to stay self contained.

Regarding packaging: We already have the git archive mechanism in place. All current releases were done like this. Lets not break this. And I went along with adding external services for optional benefits like unit testing on multiple PHP versions (travis) and the various reporting tools. But releases need to be possible with the bare minimum of tools, ideally git alone (as long as we use git as VCS we will keep that dependency). For other packaging platforms that require building we might have to add build-scripts for developers to run, but then the benefit for users should be easier install with their package manager.

Composer: I regard it as an optional helper, but it can in no way be regarded as the only way PHP should be packaged and handled. Zend supported PEAR for quite a while and has now moved towards native PHAR support. Even composer is distributed as a phar archive. In the big picture composer is a de-facto standard at best, but as long as there is no official embracement by Zend I wont bet all my horses on it.

Branching: In my opinion the master branch should be the stable branch and if we should consider to use feature or development branches in the future (as you already did, commendably). This is more a note to myself.