npm-asset/gulp issue with pretty-hrtime dependency

[einkoro]

With beta4 installed globally I am not able to install the latest version of gulp. I tried deleting the vendor directory and encountered the same error.

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for npm-asset/gulp 3.8.10 -> satisfiable by npm-asset/gulp[v3.8.10].
    - npm-asset/gulp v3.8.10 requires npm-asset/pretty-hrtime >=0.2.0,<1.0 -> no matching package found.

    "require": {
        "bower-asset/semantic": "1.1.0",
        "bower-asset/modernizr": "2.8.3",
        "npm-asset/gulp": "3.8.10"
    }

[francoispluchino]

See #73, #74. Use the 1.0.0@dev version, this bug is fixed in master branch.

[francoispluchino]

The ^ conversion is maybe bugged. I have to check this conversion.

[einkoro]

Same error on master after clearing vendor out again. Looking at the web of npm packages for gulp it looks like all of them are using ^ for specifying dependencies.

[francoispluchino]

When I corrected the ~ operator, I seem to have detected a conversion error. It could perhaps come from this conversion.

[francoispluchino]

Sorry, it's not a bug, because npm-asset/pretty-hrtime has not a tag versions. For Composer, you must edit the inline flag of version in your root composer (bacause 0.2.2 version is the alias of the dev-master branch.

{
    "require": {
        "npm-asset/pretty-hrtime": "@dev"
    }
}

[francoispluchino]

However, there is a bug with package versions added directly in the NPM Registry.

Example: npm-asset/sequencify

The dev-master has the 1.0.0 alias version, but there is 3 versions registered in the NPM Registry (0.0.5, 0.0.6, 0.0.7).

Currently, these versions are added only if the plugin can not find the VCS repository of the package. I will also include these versions whether these versions are not present in the VCS repository.

[einkoro]

Thanks for looking into this.

[francoispluchino]

Include package versions defined directly in NPM Registry: 7516e67.
Fix alias version with tilde operator: 151a519.

[francoispluchino]

@einkoro Your dependency npm-asset/gulp cannot be installed via Composer, because different dependencies requires the same dependency, but with different versions. This feature is not available in Composer.

The plugin starts to reaching a too many limitation with Composer (performance, camelcase for package name, same package with different versions), I think more and more to make a version 2.0 using nodejs but by automating the entire process for NPM/Bower:

• installation of nodejs in project vendor if nodejs is not available globally
• install/update NPM (if necessary)
• install/update Bower (if necessary)
• retrieves the NPM/Bower dependencies defined in each package (files package.json and bower.json, but also the composer.json file for keep the compatibility)
• create/update the files package.json and bower.json in root project (if necessary)
• install/update NPM dependencies (if necessary)
• install/update Bower dependencies (if necessary)
• create/update the NPM shrikwrap file (if necessary)

@qiangxue, @cebe, @samdark, I know, I still come back with this proposal, but I think this is the most reliable solution on the long term.

[cebe]

@qiangxue, @cebe, @samdark, I know, I still come back with this proposal, but I think this is the most reliable solution on the long term.

I think it is okay to add nodejs, npm and bower if it is desireable. But in general, the idea of having this plugin was to allow installation of bower packages without the need to install nodejs & co. It should still be possible to install simple bower packages without installing any nodejs stuff. For advanced usage and if nodejs is installed on the system anyway the plugin may rely on it to resolve and install dependencies.

Imo it is okay to live with some limitations if we get integration of bower packages in composer without the need to deal with another package manager. For advanced usage you have to switch to nodejs anyway.

[francoispluchino]

The idea is not to install nodejs but copy the binaries if they are not installed. In this way, the main concept of the plugin is still there. The mechanism is identical to the installation of a dependency for your project. And it will be very difficult to have 2 modes (classic and advanced).

Of course I have a preference for pure PHP, but it is more and more difficult to solve problems, especially as the PRs for Composer are unanswered for more than 6 months... So make changes for the package names, the RemoteFileSystem and the Installer may not be feasible.

But this approach allows users to install the asset dependencies, even if they have not nodejs on their machine. The plugin does not install nodejs, but copy the binaries in the folder vendor/joyent/nodejs/, and automates the configuration of the dependencies.

[cebe]

I have no idea how nodejs works but if they link dynamically to dependent libraries, copying some binaries may not work on some systems. The main reason I do not install nodejs on my servers was (at least some time ago) that the dependencies did not match for my machine.

[francoispluchino]

Of course, each binary is for each system (linux, mac, windows, and 32bit or 64bit). You can find the list in https://nodejs.org/dist/latest. The plugin detects the system and it copies the good version.

[cebe]

My point was about static vs. dynamic linking: http://en.wikipedia.org/wiki/Linker_%28computing%29#Dynamic_linking
statically linked binaries should work out of the box on most systems while dynamically linked binaries do not. If nodejs is linked statically your approach should work fine. I have just asked about this in the nodejs IRC channel, haven't got an answer yet.

[francoispluchino]

For windows, linux and mac, it's a static linking (one executable).

And I have make tests for windows and Linux: it's OK. But for the mac, I don't know, because I don't have a mac... if anyone can verify (but it should work because it is a static linking).

[cebe]

$ wget https://nodejs.org/dist/latest/node-v0.10.33-linux-x86.tar.gz
...
$  tar xzf node-v0.10.33-linux-x86.tar.gz 
$ cd node-v0.10.33-linux-x86
$ ldd bin/node 
    linux-gate.so.1 =>  (0xb76f4000)
    libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb76d2000)
    librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb76c9000)
    libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb75e3000)
    libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb75b7000)
    libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb7599000)
    libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb757e000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb73d4000)
    /lib/ld-linux.so.2 (0xb76f5000)

should work on most systems but is not 100% relyable. I am still for a fallback, if node is not installed, do it like it is done now. if node is present, use it.

[francoispluchino]

if node is not installed, do it like it is done now

Do it in pure PHP (as currently) or download binaries of nodejs?

Because I thought use first the installed version of nodejs, and download the binaries if it is not installed, and throw an exception if the plugin cannot activate nodejs (the test is performed at the plugin activation, and therefore prior to analysis of dependencies).