package php-with-extensions-7.3.25 be without phpize,and no php-dev package

[jcleng]

im new hand ,i need phpize,but not found package,how todo or how to use? thinks

[aanderse]

ping @etu and @talyz who probably know the answer without having to dig deep into code.

[etu]

@jcleng You have the dev package in php73.unwrapped.dev, I hope that it suits your needs :)

[jcleng]

@jcleng You have the dev package in php73.unwrapped.dev, I hope that it suits your needs :)

thank very much， its not easy to search

[etu]

I'm thinking that it should be possible to copy this attribute from that location to also exist in php73.dev for instance. Shouldn't be hard to do... What do you think @talyz? Good bad?

[mjsir911]

I'm running into this issue, but I need an environment where php-config points to a php binary that has an additional extension, tokenizer built in.

I understand why this line doesn't work, but my latest attempt at this:

(pkgs.php80.unwrapped.dev.withExtensions ({all, ...}: with all; [tokenizer]))

Doesn't work because phpWithExtensions's symlinkJoin's paths is only passed in php & not php.dev, right?

I think a simple fix would be to add it, but that would bloat the php packages and basically undo putting development stuff in php.dev. What's the solution?

Ideally symlinkJoin could work with multiple outputs, but that seems like a bigger ask & has additional complications

BTW this is all happening because my extension is using gen_stub.php during compile-time

[jcleng]

I'm running into this issue, but I need an environment where php-config points to a php binary that has an additional extension, tokenizer built in.

I understand why this line doesn't work, but my latest attempt at this:

(pkgs.php80.unwrapped.dev.withExtensions ({all, ...}: with all; [tokenizer]))

Doesn't work because phpWithExtensions's symlinkJoin's paths is only passed in php & not php.dev, right?

I think a simple fix would be to add it, but that would bloat the php packages and basically undo putting development stuff in php.dev. What's the solution?

Ideally symlinkJoin could work with multiple outputs, but that seems like a bigger ask & has additional complications

BTW this is all happening because my extension is using gen_stub.php during compile-time

hi bro,it may be more complicated to use in this way. this is how I deal with it when I'm developing and need some extensions. use my config https://github.com/jcleng/nix-dev-jcleng-php72-darwin (or php71 branch), and nix-build to build myself phpversion,and myself extensions, and useing ln uesed. maybe nix doesn't recommended， but its convenient and fast for dev， right

[mjsir911]

Thank you @jcleng, this seems like a reasonable short-term fix.

I would like to help push forward the php stuff in nixos though as it seems the capabilities don't support some uses that we want :)

@etu & @talyz, is it reasonable to expect this stuff to work with the shipped php stuff? I'm willing to take a jab at a solution, but I've been stumbling around so far not really knowing where to go. What was the original intention of separating out dev from out?

[mjsir911]

Alright, I think I have a solution for this, but it requires a bit of a rewrite.

php can load .ini files with PHP_INI_SCAN_DIR. This means that php.withExtensions() could just be a base php environment plus a few directories with the extension's ini configuration files.

I see that the existing phpWithExtensions uses PHP_INI_SCAN_DIR, but I don't think wrapping the /bin/php with it is enough since php-config returns an unwrapped binary, but having PHP_INI_SCAN_DIR set in the environment fixes it.

I don't have much experience with nixpkgs, but I'm going to take a shot at it. Ideally phpWithExtensions would just return the existing derivation with just an environment variable set :)

[talyz]

@etu Unfortunately, inheriting the dev output messes things up for packages depending on the wrapped php. See #84721.

@mjsir911 I'm not entirely sure I understand your use-case, but I think you should be able to build the configuration you want with phpWithExtensions and then pass that configuration to php-config using the phpIni attribute, if what you want is essentially a php-config wrapped the same way that php is. We could probably provide wrapped versions of the dev utilities as well - as you've noticed, there's no way to generate such a dev output with the current tooling.

[mjsir911]

Thank you for the response @talyz!

@etu Unfortunately, inheriting the dev output messes things up for packages depending on the wrapped php. See #84721.

This issue is actually closely related with that one, since the problem is coming down to the fact that the "dev" output doesn't inherit the extensions' configuration.

@mjsir911 I'm not entirely sure I understand your use-case

My use case is I want to build a php extension (my own php-git) which depends on the tokenizer extension being included during build time for generating stubs.

./configure is getting the php binary from php-config --php-binary, & other files/directories pointing to the same original php without extensions tree.

wrapping it in the same way won't work because wrapProgram changes the environment, & php-config is returning absolute paths to unconfigured php.

We could probably provide wrapped versions of the dev utilities as well - as you've noticed, there's no way to generate such a dev output with the current tooling.

This is what I've been trying to get towards. Would the way to go about this be something like substituteAll or substituteAllFiles substituting php-config paths with the updated php root equivalents?

[talyz]

@mjsir911 I've attempted a fix in #123535. Please try it out and see if it solves your issue.

[stale[bot]]

I marked this as stale due to inactivity. → More info

[mjsir911]

Still suffering from this