[task] generate:project command is broken

[connorhu]

Although it is not recommended to create a new project based on symfony1, it may sometimes be necessary to build a symfony1 project from scratch.

For a completely empty project, the project:generate command does not work.

Error:

PHP Warning: require_once(/Doctrine/Core.php): Failed to open stream: No such file or directory in .../vendor/friendsofsymfony1/symfony1/lib/plugins/sfDoctrinePlugin/config/sfDoctrinePluginConfiguration.class.php on line 36

PHP Fatal error: Uncaught Error: Failed opening required '/Doctrine/Core.php' (include_path='.:/Users/connor/.phpbrew/php/php-8.3.0/lib/php/pear') in .../vendor/friendsofsymfony1/symfony1/lib/plugins/sfDoctrinePlugin/config/sfDoctrinePluginConfiguration.class.php:36

Code fragment causing the error:

symfony1/lib/plugins/sfDoctrinePlugin/config/sfDoctrinePluginConfiguration.class.php

Lines 35 to 38 in 50c946b

	if (!class_exists('Doctrine_Core')) {
	require_once sfConfig::get('sf_doctrine_dir', realpath(dirname(__FILE__).'/../lib/vendor/doctrine/lib')).'/Doctrine/Core.php';
	spl_autoload_register(['Doctrine_Core', 'autoload']);
	}

Reproduction steps:

mkdir folder
cd folder
composer require friendsofsymfony1/symfony1
vendor/bin/symfony generate:project gentest

We should check if the doctrine plugin can be detached from the project and moved to a separate repo.

[mentalstring]

It seems to work with --orm=none, because it defaults to Doctrine.

Anyway, I agree that having it shipped with the framework doesn't quite make sense, although I'm partial as I only use Propel with symfony1. Having it in a separate package would also facilitate upgrading one separate from the other.

That said, I'm not sure how much work it be to do that. Perhaps a easier route on the short term could be to have it run out of the plugins directory as I think it originally used to.

[connorhu]

@mentalstring It does not seem very complicated. My biggest dilemma is how to do the separation: actually, or in a subtree layout, as the symfony does.

I have similar problems with swiftmailer. Currently the install looks like this:

  - Locking doctrine/deprecations (1.1.3)
  - Locking doctrine/lexer (2.1.1)
  - Locking egulias/email-validator (3.2.6)
  - Locking friendsofsymfony1/swiftmailer (v6.4.0)
  - Locking friendsofsymfony1/symfony1 (v1.5.19)
  - Locking symfony/polyfill-iconv (v1.29.0)
  - Locking symfony/polyfill-intl-idn (v1.29.0)
  - Locking symfony/polyfill-intl-normalizer (v1.29.0)
  - Locking symfony/polyfill-mbstring (v1.29.0)
  - Locking symfony/polyfill-php72 (v1.29.0)

I only wanted one thing out of this. The rest are added because of swiftmailer.