fatal : no remote found for dependency '....'
AaronNGray opened this issue · 20 comments
Hi,
I am getting problems finding modules/packages.
I am working in parallel on Linux and Windows.
I have done a :-
npm install -g component
And am having problems with 'visionmedia/debug' on Windows but not on Linux. But I am having problems on Linux on the top level directory install.
component install visionmedia/debug
is working fine in my 'lib/debug' directory of https://github.com/UKDemocracyOS/app on Linux
But on Windows I am getting :-
fatal : no remote found for dependency "mediavision/debug".
https://github.com/visionmedia/debug exists.
My Linux component.json files are here and I will attach the Windows ones which should be the same.
app/lib/debug/component.json
{
"name": "debug",
"dependencies": {
"visionmedia/debug": "^2.1.3"
},
"locals": [
"config"
],
"scripts": [
"index.js"
],
"main": "index.js"
}
app/component.json
{
"name": "democracyos",
"version": "0.14.0",
"description": "An online space for deliberation and voting on political proposals. The software aims to stimulate better arguments and come to better rulings.",
"paths": [
"lib"
],
"locals": [
"boot"
]
}
app/lib/boot/component.json
{
"name": "boot",
"description": "bootstrap component",
"dependencies": {
"visionmedia/page.js": "1.3.7",
"component/t": "1.0.0",
"component/bus": "^0.0.2",
"DemocracyOS/timeago": "master",
"code42day/ga": "1.1.0",
"slifszyc/user-agent": "0.0.9"
},
"locals": [
"config",
"body-classes",
"content-lock",
"homepage",
"proposal",
"law",
"signin",
"signup",
"forgot",
"settings",
"translations",
"flaticons",
"admin",
"header",
"logout",
"help",
"404",
"browser-update",
"debug"
],
"scripts": [ "boot.js" ],
"styles": [ "boot.styl", "boot-responsive.styl" ],
"images": [
"images/check.png",
"images/favicon.ico",
"images/logo.png"
],
"main": "boot.js"
}
On Windows the files are the same except the visionmedia/debug dependency is obviously missing in the lib/debug
app\lib\debug> component install visionmedia/debug
is giving :-
fatal : no remote found for dependency "mediavision/debug".
I am getting the same error message on doing a 'make' on Linux :-
fatal : no remote found for dependency "visionmedia/debug".
I don't know if I am missing doing something with componentjs at this stage ?
Okay its just being non determinate. GitHub was being DDoS'ed apparently and I think its possibly to do with this maybe as some things are now working that were not working before but for no reason. And it seems only to be with new repos, not existing ones.
I think the componentjs component architecture does not do enough retries or wait long enough at times in places like when resolving dependencies.
DEBUG=* can help to find where the error comes from, see https://github.com/componentjs/guide/blob/master/component/troubleshooting.md
component uses cogent for http requests, there is a deafult timeout of 5 seconds, but you change the timeout:
component/bin/component-install
Line 13 in 1faa776
so we can close this issue?
Thanks !
I am still having problems with 'component install' particularly redirects like tj/debug -> visionmedia/debug are still not getting resolved when the internet is busy even with a --timeout 480000
I seemed to have clear periods of working behaviour when the internet is quiet in the early hours in the UK, i.e. 6:00AM GMT.
It seems to be redirects that are hit worst, then newer created repositories, then when it very busy other modules at random. It looks like the '--timeout' flag does not work on all operations within 'component'.
I am in the UK so probably have longer latencies that the US.
I think its the component-resolve module is where the problem is occurring.
It looks like the '--timeout' flag does not work on all operations within 'component'.
Yep, I think this is the problem, here is the code:
https://github.com/componentjs/remotes.js/blob/0c32e97cc07dd2bbb7076fdf52102e514d4b7431/lib/remotes/github.js#L43
The options are not passed at this place.
Good catch, thanks!
Is it possible to solve this ?
I don't have good enough knowledge of the component codebase.
Aaron
On 8 April 2015 at 11:00, Anton Wilhelm notifications@github.com wrote:
It looks like the '--timeout' flag does not work on all operations within
'component'.Yep, I think this is the problem, here is the code:
The options are not passed at this place.
Good catch, thanks!—
Reply to this email directly or view it on GitHub
#634 (comment)
.
I was wrong, it's not the problem, I add a console.log into every request and the timeout option works fine:
awilhelm@antonsmac:~/dev/c8-experiments$ rm -rf components/tj && component-install tj/debug
timeout: 5000
timeout: 5000
outdated name of a dependency : please update: "tj/debug" -> "visionmedia/debug"
timeout: 5000
timeout: 5000
timeout: 5000
timeout: 5000
timeout: 5000
installed : tj/debug@2.1.3 in 2186ms
install : complete
awilhelm@antonsmac:~/dev/c8-experiments$ rm -rf components/tj && component-install --timeout 20000 tj/debug
timeout: 20000
timeout: 20000
outdated name of a dependency : please update: "tj/debug" -> "visionmedia/debug"
timeout: 20000
timeout: 20000
timeout: 20000
timeout: 20000
timeout: 20000
installed : tj/debug@2.1.3 in 1347ms
install : complete
Cannot go further without any debug lines
Anton,
As I am experiencing the problem at this end I suppose I need to do the
debugging here.
Is it possible you can push what you have done onto a github repo or branch
and give me instructions on how to set it up for debugging ?
On 8 April 2015 at 17:58, Anton Wilhelm notifications@github.com wrote:
Cannot go further without any debug lines
—
Reply to this email directly or view it on GitHub
#634 (comment)
.
DEBUG=* can help to find where the error comes from, see https://github.com/componentjs/guide/blob/master/component/troubleshooting.md
I just added a console.log after this line with the ´timeout` value: https://github.com/timaschew/cogent/blob/patch-1/lib/index.js#L39
So search for this file within your node_modules. Be careful, if you using node without generators you need to use the index file in the build directory instead of in the lib.
Yeah I have tried DEBUG=* but there seem to be no debug lines at the
relevant points so I suppose I need to further instrument the code.
I have found the line that throws up the actual fatal throw line :-
node_modules/component/node_modules/component-resolver/build/semver.js:565
Not sure how the build directory gets there from looking at componentjs/resolver.js
I find this code very hard to follow !
line 565 form in build comes from line 130 in the source: https://github.com/componentjs/resolver.js/blob/master/lib/semver.js#L130
I find this code very hard to follow !
you should not read the build, it's a generated code, switch to node 0.12 with --harmony or just use iojs, then you can read and execute the raw code (in the lib directory)
Okay seemed to have fixed it by using long timeouts of 240000ms I will close this issue as soon as the it has been tested at peak US and UK internet access time, later today.
Ah its still not working on a Windows VMWare with Fedora installed, even with a timeout of 480000 !
So there is some form of timing latency or retry problem, probably not enough reties at some points in the code.
Okay its not working on deployment on my Fedora F20 i686 HP DL140 G3 Dual Core Servers
I think either there is a race condition in the code or there are no retries or not enough retries.
win64 with npm v2.1.18
npm install component fails for certain shells: msys32 msys64, cygwin64 bash - POSIX filenaming incompatibiliity.
use regular cmd or git bash
I use CMD on Windows. But was getting the problem there at times of high
level internet usage, when UK and US were quiet the problemS ceased.
It still looks like a timing and retry issue to me. As it also happens on
Linux VM's under VMWare on Windows. And on my Fedora 21 Linux machine too.
Its intermittent basically.
On 26 April 2015 at 07:10, rickdog notifications@github.com wrote:
win64 with npm v2.1.18
npm install component fails for certain shells: msys32 msys64, cygwin64
bash - POSIX filenaming incompatibiliity.use regular cmd or git bash
—
Reply to this email directly or view it on GitHub
#634 (comment)
.