yeah looks like a massive perf issue. I will investigate
/cc @isaacabraham

I just reverted that change. Can just please check if perf is restored? Seems I need to investigate deeper

pushed 2.52.12 - I think I verschlimmbessert it in 2.52.11

Tested it with 2.52.12. and it's back to normal. Thx.

OK now I need to find a proper fix for #1520
@Stift I guess I need to push another version soon and ask you again if perf is still good ;-)

Just do so. I'm glad to test it.
But today is St. Patricks Day and I'm off and out in a few hours:

2.52.13 will be online in 2min. Please give it a try

that will fit

so it's online

I'm already testing it. I get some warnings that I cannot specifcally say what they are about:

Could not resolve package Npgsql:
 - Dependencies file requested: 2.2.5-custom
 - <customPackage1> 1.0.11044 requested: >= 0
 - <customPackage2> 1.0.11149 requested: >= 2.2.5
 - <customPackage3> 1.1.10087 requested: >= 2.0.0 < 3.0.0

Also some of the numbers do not fit to the package itself. Is something mixing up here?

shit. soo I'm not done

Also after a second run of install downloads now all packages again and this again takes a while.
First run: 26s
Second run (downloading?): 5min

sorry for that

ok this one is really driving me nuts.

I released another version. Can you give me your deps file by any chance?

I'll send it to you, but it contains many of our own packages and we use also a Klondike server as backend. i'll send it to you via mail.

i guess this means 2.52.14 is still broken...

It has the same strange warning as before, but this time it does not tries to redownload.

I have sent you our dep file per mail.

just trying to reproduce with your deps file, but I assume in order to make it really hard the conflict is only in your custome nugets ;-)

no worries. I can pin paket for now. For today I'm out. I have some assumption on that as well. Before monday I will not get into that. Would be glad if you can give me a hint what I should look at. Lately I saw on the verbose level that one package was repeatedly tried to "retrieve information".

so the public part of your deps file resolves without error. I guess we need to look into this next week.

@forki what do you think to separate releases into stable and beta channels because these frequent changes with high potential for regression, are affecting people day to day work.

we usally do that, but the v3 branch is blocking the alpha channel.
I aslo starting to add property based test around this part.

Maybe you need 3 channels, stable, alpha for bigger longer changes and beta for smaller one

Ok. I think I found the error in our package that was causing the warning:

Could not resolve package Npgsql:
 - Dependencies file requested: 2.2.5-custom
 - <customPackage1> 1.0.11044 requested: >= 0
 - <customPackage2> 1.0.11149 requested: >= 2.2.5
 - <customPackage3> 1.1.10087 requested: >= 2.0.0 < 3.0.0

The <customPackage2> had its dependency too strict and therefore the Npgsql.2.2.5-custom was not fitting in its constraint. It was obvious after I saw it. The first time I misread the warning and thought that the customPackages were requested, but this morning I just discovered that it was meant in a way that this package requested npgsql of this version.

So what paket says is correct?

Yes. I misunderstood the message! Sorry for that confusion.

If I read the message like this, I would maybe understand this earlier.
Could not resolve package Npgsql:
- Dependencies file requested package Npgsql: 2.2.5-custom
- 1.0.11044 requested package Npgsql: >= 0
- 1.0.11149 requested package Npgsql: >= 2.2.5
- 1.1.10087 requested package Npgsql: >= 2.0.0 < 3.0.0

Should I make a pr for this?

Yes everything that improves error messages is good.
On Mar 18, 2016 18:03, "Christian Fiebrig" [email protected] wrote:

Yes. I misunderstood the message! Sorry for that confusion.

If I read the message like this, I would maybe understand this earlier.
Could not resolve package Npgsql:

• Dependencies file requested package Npgsql: 2.2.5-custom
• 1.0.11044 requested package Npgsql: >= 0
• 1.0.11149 requested package Npgsql: >= 2.2.5
• 1.1.10087 requested package Npgsql: >= 2.0.0 < 3.0.0

Should I make a pr for this?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1524 (comment)

@Stift seems that I need your help again. Property based testing revealed another issue around that code. I was able to fix that but I want to know if how bad the perf is. Can you please check 3.0.0-alpha079? Thanks mate

No problem.
stats for paket install

and for a paket update nuget package only on a clean commit

The unclean commit was the one that originally made problems and where we had a package which was not configured well.

I mean the only issue that I see is that with this unclean package we get into a situation where paket does not behave that well. When I looked in the verbose output of 2.52.10 (where the original problem started) I had the feeling paket was running in circles.

So apart from a strange state it was ok?

yes. Seems like current stable and alpha are similiar.

I just fear a bad user experience when paket cannot detect that it runs in a regression.

Yes we need to find that error. Question is how to reproduce on my machine.
On Mar 22, 2016 8:56 PM, "Christian Fiebrig" [email protected]
wrote:

I just fear a bad user experience when paket cannot detect that it runs in
a regression.

—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
#1524 (comment)

ok I added another 3.0alpha package. I hope it solves that 2h hour thing

I tested with 3.0.0-alpha80 and with the unclean package paket install takes about 27 seconds. On a clean repo without the failing package we still have around 15 seconds. For me this looks definetely better and acceptable (from a user perspective).

Update is also fine on the clean one.

thanks buddy.

no problem. Glad to serve and give something back.