Does API manual nuget downloads come with the package dependencies?

-

No, unless the package intentionally includes them.

By manual you mean downloading a nupkg? It's just a zip, you can unzip it and check for yourself

But generally no

yes

Let's suppose that my package Banana.MyPackage depends on Potato.Utils

If I download Banana.MyPackage and reference it directly into my project without downloading Potato.Utils and doing the same thing will I get an error?

you have to dowload both manually

the question is why you're doing it

it's better to reference the package, in which case dependencies are resolved (in most cases)

I'm writing a package manager

To JavaScript projects that are using .NET assemblies

your question is the reason package manager exists

because package alone won't do anything

pacakge manager are in charge to make sure version range are both computed and respected

and also make decision on the tree resolution when a version range match multiple element on which to choose

gotcha

if you decide to write a full package manager

make sure Lockfile are defacto enabled

and that you version both the declaration file as well at the lockfile

taking notes

thanks

the hard part you're gonna have to deal with is the "version strategy", one for direct, one for transitive

do you go for highest of lowest for one / both / none ?

which "version range" goes with "wildcard" and ([ ]) (like math) in dotnet or weird notation in JS with ~^ ...

I'm doing something like npm

i dislike the npm notation

i mean the ^ ~ ...

I'm doing like that because the target is a Js .NET runtime

you have know by heart the meaning of ^ and ~ => everyone is confused until they learn

so I will have a way to dyamically install .NET packages in the js environment

the 1.2.* is more obvious

or [1.2.3, 3.0.0)

the * is nice

* make is hard to supposer "at least 1.2.3

In my logic * means latest of the section

like

because 1.2.* allow 1.2.0 and 1.2.1 and 1.2.2

1.1.* means that will be the latest patch

yeah the "higest/latest"

that can be 1.1.1, 1.1.2... whatever is the latest patch

fair but that's not how package manager works 😄

if you project depends on A B C

if you project depends on A B C DIRECTLY

A : * with transitive => B
B : * with transitive => C [1.1.0, 1.2.2]
C : 1.2.*

and there's a 1.2.4 for C
what do you do ?

So

what if isolated dependencies 😈

that's not a thing

you have to build a tree first

and then compute version

but ...

tu create the tree you need version

lol

because transitive change

and the tree / graph change

My project having dependency to Potato 2.3.2 but another dependency of my project depends on Potato 2.1.1, then, that dependency will have its own isolated version of Potato without having nothing with my direct Potato dependency

take the above example

Im truly thinking about clone npm and changing its interface to access nuget instead of npmjs

making the needed adaptations

your description tells
* latest A
* latest B
* C: 1.2.latest patch

but B transitive on C is not compliant

becuase its version range is blocked as 1.2.2 not 1.2.4

jeez I hate graphs

which is why I told you earlier 😄

it all depends on your version range strategy

Yeah

It is a good challenge for my free time

and why 1.2.* is tricky

agressive latest ? flexible latest ? whatever makes stuff happy ?

but at the same time it uses 0 at the minimal "flexible"

Following the npm standards, static version until update command

where [1.2.2, 1.2.9999) set both minmal included and maximal excluded

mmm

it looks ugly through

😄

why didnt they choose < and > insetad of [ )

math

standard notation

🥺

[] for include and () for exclude

gotcha

maybe there's another reason

but that's how i like to see it

I might be wrong

now I'm guessing that's what npm tried to do with:

^1.2.2 and ~1.2.2

but i find it hacky

good question

^ is for minor IIRC

and ~ for patch

it act as a wildcard for a segment

it also allow "foo":"latest"

equivalent of "Foo": "*" in dotnet

dotnet will use "lowest resolution" for transitive which ... i don't like either because it has the tendancy to drag down legacy

but have the benefits to get the most chance for a resolved tree

(you entered chaos world :D)

the hard part is that the "info" of all package / all version / all transitive is so huge that a bruteforce is fucking diffuclt very fast

especially in JS where the ecosystem made it stupid and never actually consolidated a common base (like the CLR)

the the number of packge skyrocket for stuff that does 10 / 20 lines

which make it slower