Conditional package dependencies?

Hi,

we like to publish a new DataSource driver for
Structures_DataGrid soon. 
This new driver will combine the current DBQuery and MDB2
drivers (which 
will be marked as deprecated then), and add additional
support for PDO.

Because of the usage of a try/catch block around the PDO
constructor, we 
need to require PHP 5 for the new driver, while
Structures_DataGrid 
itself remains PHP 4 compatible.

The problem now is that we want to make the new SQLQuery
driver the 
default driver for PHP 5 users if a SQL query is passed to
the bind() 
method. This modified auto-detection would require that our
users have 
the new SQLQuery driver installed; otherwise backwards
compatibility 
would be broken.

To keep it short: Is there a way to define a conditional
dependency that 
requires the new driver if PHP 5 is used, and that defines
only an 
optional dependency if PHP 4 is used?

Other suggestions on this problem are also welcome, of
course.

Regards,
Mark

-- 
http://www.markwiesemann.
eu

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Hi,

So I could use the SQL driver on PHP 4 if I use dbquery or
mdb2, right ?

Really the only thing you can do is have php 4 and php 5 as
optional, the
only real way is to have things split up so that you can
have proper deps,
that I know of anyway.

- Helgi

On 6/8/07, Mark Wiesemann <wiesemannphp.net> wrote:
>
> Hi,
>
> we like to publish a new DataSource driver for
Structures_DataGrid soon.
> This new driver will combine the current DBQuery and
MDB2 drivers (which
> will be marked as deprecated then), and add additional
support for PDO.
>
> Because of the usage of a try/catch block around the
PDO constructor, we
> need to require PHP 5 for the new driver, while
Structures_DataGrid
> itself remains PHP 4 compatible.
>
> The problem now is that we want to make the new
SQLQuery driver the
> default driver for PHP 5 users if a SQL query is passed
to the bind()
> method. This modified auto-detection would require that
our users have
> the new SQLQuery driver installed; otherwise backwards
compatibility
> would be broken.
>
> To keep it short: Is there a way to define a
conditional dependency that
> requires the new driver if PHP 5 is used, and that
defines only an
> optional dependency if PHP 4 is used?
>
> Other suggestions on this problem are also welcome, of
course.
>
> Regards,
> Mark
>
> --
> http://www.markwiesemann.
eu
>
> --
> PEAR Development Mailing List (http://pear.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub
.php
>
>

Hi,

Helgi Þormar Þorbjörnsson wrote:
> So I could use the SQL driver on PHP 4 if I use dbquery
or mdb2, right ?

Yes, you can already do it and you will still be able to do
it after the 
SQLQuery driver is available. But new things will likely
only be 
implemented in the new driver.

> Really the only thing you can do is have php 4 and php
5 as optional, 
> the only real way is to have things split up so that
you can have proper 
> deps, that I know of anyway.

Looks like we have to wait for Pyrus (and request such deps
for it), but 
maybe Greg has a good idea for this problem?

Regards,
Mark

-- 
http://www.markwiesemann.
eu

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Seems like the PHP4 / PHP5 barrier is significant enough to
justify allowing
separate dependency sections in package.xml, one for each
"PHP generation",
which can later be extended to include the PHP6 generation. 
Or, perhaps
each dependency object itself could be allowed to have its
"required vs.
optional" dependency attribute work in tandem with a
PHP Generation
attribute, so that Mark could spec that his dependency X is
optional for
PHP4 but required for PHP5.  However, thinking this out
further, people
would probably later want to expand it into PHP versions
rather than
generations, so the one or two barrier boundaries would grow
significantly.

If I had put this kind of construct in my code, to where I'm
checking to see
if a particular capability is available (PHP5) and fall back
to something
else if it's not (PHP4), then I'd probably choose to mark
the PHP4
dependency as required (MUST be there for the fallback) and
the PHP5
dependency as optional (HOPE it's there because I obviously
like it better
than what's in the fallback dependency).  Then, it's up to
me to put in the
README/INSTALL that "if you have PHP5, you SHOULD
choose to install optional
dependency X to take advantage of better performance /
handling-on-wet-curves-during-heavy-wind / whatever."

I don't think I can talk myself into messing with the
complexity of trying
to bend the installer's dependency resolution into handling
this scenario
just for "ultimate flexibility" in what I want
installed.  It would be up to
me, the one choosing to put such a construct in my code, to
be responsible
for working up an acceptable use of the capabilities of the
dependency
resolution mechanism at my disposal.  I can see the benefits
of coding
things like this, trying to take advantage of the new/better
things while
also failsafing back to old/works things, but bending the
installer to deal
with such seems to me like it would make the dependency
resolution logic an
order of magnitude more complex, and therefore not a good
tradeoff in the
end.

If my reply reads like a stream of thought as the thought
progressed, it's
because that's exactly what happened.  I didn't start
talking myself OUT of
the idea until I'd nearly finished the first paragraph.
-- 
CRB

Let me introduce you to my very own DMCA-protected
encryption key:
BC 1B 64 4A 8D DE 49 E8 C3 7D CC EE 1A AD EE F5
(compliments of Freedom-to-Tinker http://www.f
reedom-to-tinker.com/?p=1155)

Mark Wiesemann wrote:
> Hi,
> 
> we like to publish a new DataSource driver for
Structures_DataGrid soon.
> This new driver will combine the current DBQuery and
MDB2 drivers (which
> will be marked as deprecated then), and add additional
support for PDO.
> 
> Because of the usage of a try/catch block around the
PDO constructor, we
> need to require PHP 5 for the new driver, while
Structures_DataGrid
> itself remains PHP 4 compatible.
> 
> The problem now is that we want to make the new
SQLQuery driver the
> default driver for PHP 5 users if a SQL query is passed
to the bind()
> method. This modified auto-detection would require that
our users have
> the new SQLQuery driver installed; otherwise backwards
compatibility
> would be broken.
> 
> To keep it short: Is there a way to define a
conditional dependency that
> requires the new driver if PHP 5 is used, and that
defines only an
> optional dependency if PHP 4 is used?
> 
> Other suggestions on this problem are also welcome, of
course.

Hi,

There is one possibility that may be a bit onerous. 
Basically, your
only hope is to take advantage of the new pre-download PHP
dependency
resolution in PEAR 1.6.0.

What you could do is have the 1.0.x versions of SQLQuery
driver simply
be a wrapper for the default php 4 driver, and 1.1.x
versions of
SQLQuery driver be the php 5 driver.  However, for this to
work, you'd
need the API to be BC between 1.1.x and 1.0.x.  If the
php4/php5
machinations are all under the hood, this solution would
actually work
and satisfy PEAR's API BC requirements

Greg

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Hi Greg,

Greg Beaver wrote:
> Mark Wiesemann wrote:

>> To keep it short: Is there a way to define a
conditional dependency that
>> requires the new driver if PHP 5 is used, and that
defines only an
>> optional dependency if PHP 4 is used?
> 
> There is one possibility that may be a bit onerous. 
Basically, your
> only hope is to take advantage of the new pre-download
PHP dependency
> resolution in PEAR 1.6.0.

Okay, so we need to require PEAR >= 1.6.0

> What you could do is have the 1.0.x versions of
SQLQuery driver simply
> be a wrapper for the default php 4 driver, and 1.1.x
versions of
> SQLQuery driver be the php 5 driver.  However, for this
to work, you'd
> need the API to be BC between 1.1.x and 1.0.x.  If the
php4/php5
> machinations are all under the hood, this solution
would actually work
> and satisfy PEAR's API BC requirements

If I understand correctly you mean that:

- SDG_DS_SQLQuery 1.0.x wouldn't provide any file by its own
but depend on:
    - PHP4
    - SDG_DS_DBQuery (the old DB-based driver)
    - SDG_DS_MDB2 (the old MDB2-based driver)

- SDG_DS_SQLQuery 1.1.x would provide the new driver's files
and depend on:
    - PHP5

- Structures_DataGrid would depend on:
    - SDG_DS_SQLQuery >= 1.0

Then the pear installer would download the 1.0.x version if
it detects PHP4, and
the 1.1.x or later version otherwise. Is this right?

It seems to me like it wouldn't create any maintaining
overhead.. That seems to
be the perfect solution 

Regards,

--
  Olivier

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Olivier Guilyardi wrote:
> Hi Greg,
>
> Greg Beaver wrote:
>   
>> Mark Wiesemann wrote:
>>     
>
>   
>>> To keep it short: Is there a way to define a
conditional dependency that
>>> requires the new driver if PHP 5 is used, and
that defines only an
>>> optional dependency if PHP 4 is used?
>>>       
>> There is one possibility that may be a bit onerous.
 Basically, your
>> only hope is to take advantage of the new
pre-download PHP dependency
>> resolution in PEAR 1.6.0.
>>     
>
> Okay, so we need to require PEAR >= 1.6.0
>
>   
>> What you could do is have the 1.0.x versions of
SQLQuery driver simply
>> be a wrapper for the default php 4 driver, and
1.1.x versions of
>> SQLQuery driver be the php 5 driver.  However, for
this to work, you'd
>> need the API to be BC between 1.1.x and 1.0.x.  If
the php4/php5
>> machinations are all under the hood, this solution
would actually work
>> and satisfy PEAR's API BC requirements
>>     
>
> If I understand correctly you mean that:
>
> - SDG_DS_SQLQuery 1.0.x wouldn't provide any file by
its own but depend on:
>     - PHP4
>     - SDG_DS_DBQuery (the old DB-based driver)
>     - SDG_DS_MDB2 (the old MDB2-based driver)
>
> - SDG_DS_SQLQuery 1.1.x would provide the new driver's
files and depend on:
>     - PHP5
>
> - Structures_DataGrid would depend on:
>     - SDG_DS_SQLQuery >= 1.0
>
> Then the pear installer would download the 1.0.x
version if it detects PHP4, and
> the 1.1.x or later version otherwise. Is this right?
>
> It seems to me like it wouldn't create any maintaining
overhead.. That seems to
> be the perfect solution 

Hi Olivier,

This is indeed the solution I'm talking about.  Be
forewarned that this
will result in some really long version numbers like 1.0.48
and 1.1.94
if you do a lot of releases .

However, you would need to make sure that code written to
use
SDG_DS_SQLQuery 1.0.x will continue to work *unaltered* if
the user
upgrades the underlying PHP installation to version 5.x from
4.x. 
Otherwise the code is by definition not BC.

This means that, for instance, if the 4.x returns PEAR_Error
objects,
you need to have a flag in SDG_DS_SQLQuery that enables
exceptions, but
returns PEAR_Error by default (try/catch internal magic can
perform this
task quite easily)

Greg

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Gregory Beaver wrote:
> Olivier Guilyardi wrote:

>> If I understand correctly you mean that:
>>
>> - SDG_DS_SQLQuery 1.0.x wouldn't provide any file
by its own but depend on:
>>     - PHP4
>>     - SDG_DS_DBQuery (the old DB-based driver)
>>     - SDG_DS_MDB2 (the old MDB2-based driver)
>>
>> - SDG_DS_SQLQuery 1.1.x would provide the new
driver's files and depend on:
>>     - PHP5
>>
>> - Structures_DataGrid would depend on:
>>     - SDG_DS_SQLQuery >= 1.0
>>
>> Then the pear installer would download the 1.0.x
version if it detects PHP4, and
>> the 1.1.x or later version otherwise. Is this
right?
> 
> This is indeed the solution I'm talking about.  Be
forewarned that this
> will result in some really long version numbers like
1.0.48 and 1.1.94
> if you do a lot of releases .

Actually, I don't see any reason to release anything else
that 1.0 in the 1.0.x
series. Whenever we release a new version of SDG_DS_DBQuery
or SDG_DS_MDB2, the
pear installer should install the latest PHP4-compatible
version.

And what's wrong with normal numbering starting from 1.1? We
could release 1.2,
1.3, etc.. as long as 1.0 is the only release that's not
compatible with PHP5.

Am I right?

> 
> However, you would need to make sure that code written
to use
> SDG_DS_SQLQuery 1.0.x will continue to work *unaltered*
if the user
> upgrades the underlying PHP installation to version 5.x
from 4.x. 
> Otherwise the code is by definition not BC.

Well, if the user calls SDG::bind() and doesn't deal
directly with the driver
there should be no BC. But if he instantiates the driver
class directly (which
he perfectly has the right to), then he might try to deal
with classes that do
not exist anymore starting from SDG_DS_SQLQuery 1.1.

So, I should correct my above list as follow:

- SDG_DS_SQLQuery 1.1.x (and later) would depend on:
    - PHP5
    - SDG_DS_DBQuery
    - SDG_DS_MDB2

That should fix it.

> This means that, for instance, if the 4.x returns
PEAR_Error objects,
> you need to have a flag in SDG_DS_SQLQuery that enables
exceptions, but
> returns PEAR_Error by default (try/catch internal magic
can perform this
> task quite easily)

I see your point... Bad thing indeed. A such flag is
bloat-ish IMO. I feel like
there might other similar issues, that might lead us to
write obfuscated code.

I'm starting to wonder if it wouldn't be better to simply
mark SQL_DS_DBQuery
and SQL_DS_MDB2Query as superseded by SDG_DS_SQLQuery on
their respective
homepages and in the manual, the later being PHP5 only.

Anyway all drivers must be manually installed, they are
subpackages. So the fact
that SDG depends on a PHP5 driver shouldn't create
installation problems on PHP4.

Mark, what's your point of view?

Regards,

--
  Olivier

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On 6/11/07, Olivier Guilyardi <ojaimlnerim.net> wrote:
>
> Gregory Beaver wrote:
> > Olivier Guilyardi wrote:
>
> >> If I understand correctly you mean that:
> >>
> >> - SDG_DS_SQLQuery 1.0.x wouldn't provide any
file by its own but depend
> on:
> >>     - PHP4
> >>     - SDG_DS_DBQuery (the old DB-based
driver)
> >>     - SDG_DS_MDB2 (the old MDB2-based driver)
> >>
> >> - SDG_DS_SQLQuery 1.1.x would provide the new
driver's files and depend
> on:
> >>     - PHP5
> >>
> >> - Structures_DataGrid would depend on:
> >>     - SDG_DS_SQLQuery >= 1.0
> >>
> >> Then the pear installer would download the
1.0.x version if it detects
> PHP4, and
> >> the 1.1.x or later version otherwise. Is this
right?
> >
> > This is indeed the solution I'm talking about.  Be
forewarned that this
> > will result in some really long version numbers
like 1.0.48 and 1.1.94
> > if you do a lot of releases .
>
> Actually, I don't see any reason to release anything
else that 1.0 in the
> 1.0.x
> series. Whenever we release a new version of
SDG_DS_DBQuery or
> SDG_DS_MDB2, the
> pear installer should install the latest
PHP4-compatible version.
>
> And what's wrong with normal numbering starting from
1.1? We could release
> 1.2,
> 1.3, etc.. as long as 1.0 is the only release that's
not compatible with
> PHP5.
>
> Am I right?


Wrong, you can't break  BC after a stable release unless you
make a major
version.

- Helgi

Helgi Þormar Þorbjörnsson wrote:
> On 6/11/07, *Olivier Guilyardi* <ojaimlnerim.net
> <mailto:ojaimlnerim.net>> wrote:
>
>     Gregory Beaver wrote:
>     > Olivier Guilyardi wrote:
>
>     >> If I understand correctly you mean that:
>     >>
>     >> - SDG_DS_SQLQuery 1.0.x wouldn't provide
any file by its own
>     but depend on:
>     >>     - PHP4
>     >>     - SDG_DS_DBQuery (the old DB-based
driver)
>     >>     - SDG_DS_MDB2 (the old MDB2-based
driver)
>     >>
>     >> - SDG_DS_SQLQuery 1.1.x would provide the
new driver's files
>     and depend on:
>     >>     - PHP5
>     >>
>     >> - Structures_DataGrid would depend on:
>     >>     - SDG_DS_SQLQuery >= 1.0
>     >>
>     >> Then the pear installer would download the
1.0.x version if it
>     detects PHP4, and
>     >> the 1.1.x or later version otherwise. Is
this right?
>     >
>     > This is indeed the solution I'm talking about.
 Be forewarned
>     that this
>     > will result in some really long version
numbers like 1.0.48 and
>     1.1.94
>     > if you do a lot of releases .
>
>     Actually, I don't see any reason to release
anything else that 1.0
>     in the 1.0.x
>     series. Whenever we release a new version of
SDG_DS_DBQuery or
>     SDG_DS_MDB2, the
>     pear installer should install the latest
PHP4-compatible version.
>
>     And what's wrong with normal numbering starting
from 1.1? We could
>     release 1.2,
>     1.3, etc.. as long as 1.0 is the only release
that's not
>     compatible with PHP5.
>
>     Am I right?
>
>
> Wrong, you can't break  BC after a stable release
unless you make a
> major version.
Hi,

Helgi, I think you may have misread what Olivier is saying. 
1.0.x/1.1.x
would be backwards compatible, the question was whether they
can't just
go to 1.2.x (php5 + new fangled features) from 1.1.x (php5)
as long as
1.0.x is always the PHP4 version.  The answer is yes 

Greg

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php