pickle doesn't respect default configure options

[derickr]

For the mongodb/mongo-php-driver extension, pickle does not respect the default option for enabling SSL. In our config.m4, --with-openssl-dir by default is set to true, but pickle uses --without-openssl-dir when you use the -n flag. It also uses --without-openssl-dir when you just press enter for each of the options without -n:

derick@singlemalt:/tmp/pickle $ bin/pickle -n install mongodb
  - Installing mongodb (latest-stable): Downloading (100%)         
+-----------------------------------+---------+
| Package name                      | mongodb |
| Package version (current release) | 1.2.8   |
| Package status                    | stable  |
+-----------------------------------+---------+
The following error(s) happened: configure failed, see log at /tmp/pickle-42ad7f47688e6bdf7b6c6cf9875adf308065564b\config.log
1: phpize
2: Configuring for:
2: PHP Api Version:         20160303
2: Zend Module Api No:      20160303
2: Zend Extension Api No:   320160303
1: /tmp/mongodb/mongodb-1.2.8/configure --enable-mongodb=shared  --without-openssl-dir --without-system-ciphers --without-libbson --without-libmongoc --without-mongodb-sasl
2: checking for grep that handles long lines and -e... /bin/grep
2: checking for egrep... /bin/grep -E
2: checking for a sed that does not truncate output... /bin/sed
2: checking for cc... cc
2: checking whether the C compiler works... yes
2: checking for C compiler default output file name... a.out
2: checking for suffix of executables...
2: checking whether we are cross compiling... no
2: checking for suffix of object files... o
2: checking whether we are using the GNU C compiler... yes
2: checking whether cc accepts -g... yes
2: checking for cc option to accept ISO C89... none needed
2: checking how to run the C preprocessor... cc -E
2: checking for icc... no
2: checking for suncc... no
2: checking whether cc understands -c and -o together... yes
2: checking for system library directory... lib
2: checking if compiler supports -R... no
2: checking if compiler supports -Wl,-rpath,... yes
2: checking build system type... x86_64-unknown-linux-gnu
2: checking host system type... x86_64-unknown-linux-gnu
2: checking target system type... x86_64-unknown-linux-gnu
2: checking for PHP prefix... /usr/local/php/7.1dev
2: checking for PHP includes... -I/usr/local/php/7.1dev/include/php -I/usr/local/php/7.1dev/include/php/main -I/usr/local/php/7.1dev/include/php/TSRM -I/usr/local/php/7.1dev/include/php/Zend -I/usr/local/php/7.1dev/include/php/ext -I/usr/local/php/7.1dev/include/php/ext/date/lib
2: checking for PHP extension directory... /usr/local/php/7.1dev/lib/php/extensions/debug-non-zts-20160303
2: checking for PHP installed headers prefix... /usr/local/php/7.1dev/include/php
2: checking if debug is enabled... yes
2: checking if zts is enabled... no
2: checking for re2c... re2c
2: checking for re2c version... 0.16 (ok)
2: checking for gawk... gawk
2: checking whether to enable mongodb support... yes, shared
2: checking OpenSSL dir for mongodb... no
2: checking whether to use system default cipher list instead of hardcoded value... no
2: checking PHP version... 70104
2: checking whether to enable developer build flags... no
2: checking whether to enable code coverage... no
2: checking whether to use system libbson... no
2: checking whether to use system libmongoc... no
2: checking configuring libmongoc... ...
2: checking for pkg-config... /usr/bin/pkg-config
2: configure: error: Cannot find OpenSSL's <evp.h>

[Hywan]

Thanks. I will try to take a look at it!

[pierrejoye]

` php bin/pickle install --dry-run mongodb-stable

• Installing mongodb (latest-stable): Downloading (100%)
  +-----------------------------------+---------+
  | Package name | mongodb |
  | Package version (current release) | 1.7.4 |
  | Package status | stable |
  +-----------------------------------+---------+
  [whether to compile against system libraries instead of bundled] (default: ):
  [whether to use system libbson] (default: ):
  [whether to use system libmongoc] (default: ):
  [whether to enable client-side encryption] (default: ):
  [whether to enable developer build flags] (default: no):
  [whether to enable code coverage] (default: no):`

Confirmed still. The first 3 has default values.

[pierrejoye]

Also Mongodb started to use weird version again for beta, like 1.8.9beta1, which is not semver (pecl allows it), so we may add a notice at packaging time tho'.

[jmikola]

Also Mongodb started to use weird version again for beta, like 1.8.9beta1, which is not semver (pecl allows it)

I'm aware that it's invalid per SemVer's BNF, but I was under the impression that this was the particular format required by PECL. Am I mistaken?

The xdebug package uses similar tags, although that may not be saying much since @derickr was involved in both packages.

[derickr]

On 13 July 2021 21:07:16 BST, Jeremy Mikola ***@***.***> wrote: > Also Mongodb started to use weird version again for beta, like 1.8.9beta1, which is not semver (pecl allows it) I'm aware that it's invalid per [SemVer's BNF](https://semver.org/#backusnaur-form-grammar-for-valid-semver-versions), but I was under the impression that this was the particular format required by PECL. Am I mistaken? The [xdebug](https://pecl.php.net/package/xdebug) package uses similar tags, although that may not be saying much since @derickr was involved in both packages.

It's what is the standard for PHP versions is, as documented with PHP's version_compare function: https://www.php.net/manual/en/function.version-compare.php That's what PECL (and PEAR) versions were modeled after, way before semver was formalised. So no, this is not weird, and very much in line with PECL and PEAR package versions look like.

[pierrejoye]

Aloha,

Weird is a bad word. Sorry, it is more about SemVer or not.

In any case, we have two choices (sorry, PEAR is not part of that :), either we support fully version_compare or we follow SemVer only, which is what composer does.

I tend to go with the later as it solves a load of issues when it comes to versioning and deps between composer and extensions, besides duplicating all comparison and check versions codes. Also PHP extensions are no longer in their own silos, there are more and more strong dependencies between Composer packages and extensions (hence the creation of pickle). Some standard to follow would be good, and there are little to no alternative but composer when it comes to PHP packages.

So either makes end users life easier or developers life easier. Tough choice :)

What do you think?

[pierrejoye]

@jmikola also it is not required by PECL. It is supported by PECL due to version_compare usage. This is a key difference.

SemVer would work perfectly fine with PECL if used.

[jmikola]

also it is not required by PECL. It is supported by PECL due to version_compare usage. This is a key difference.

Noted. Even if ext-mongodb were to start using a semver-compliant format for prerelease versions going forward, would there be issues with old releases? I realize the problem may just sort itself out in due time, since projects would be less likely to depend on older versions with non-semver tag names.

Another thought: Assuming the version_compare format is consistently followed across existing extensions, would it be feasible for pickle to up-convert invalid version strings to the semver format (e.g. change 1.0.0BETA1 to 1.0.0-beta.1). Is that just a matter of having someone spend the time to write it, or are there technical reasons or other objections to implementing such a thing?

[pierrejoye]

As of an extension using semver, there will be no issue if the version number is different. In pecl.php.net, the status is handled separately than the version. The version like 1.0.1beta1 exists to allow 1.0.1beta1, 1.0.1beta2 etc. which is redundant with the status and version numbers are infinite ;).

Also I really really tend to go with SemVer for pickle and only support install with force mode for other. It will be an absolute nightmare for users to handle version deps with a completely different scheme. F.e. as of Mongo, given they have PHP and ext, I suppose it would make sense to have them using the same scheme.

It is slightly more than spending time on implementing, it is also about spending time to explain to users why it is different and maintain that different scheme. :)