Skip to content

DNX: dealing with non-NuGet repositories? #834

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ghost opened this issue Aug 15, 2015 · 3 comments
Closed

DNX: dealing with non-NuGet repositories? #834

ghost opened this issue Aug 15, 2015 · 3 comments

Comments

@ghost
Copy link

ghost commented Aug 15, 2015

Hello.

While CoreCLR and DNX now is not just for aspnet - I have question about high-level design or concept for this parts (I.e. DNX), which are touched to nuget.

In short form it is can sounds as - it is possible to replace nuget with some other package manager? I'm understand that short answer is no (without improve something). But... for technologies it is not looks as answer.

Nuget initially do lot of implications, which are not now fit. Nuget become popular and it is used now even for deployment, but during development - it is used for binary distributions of native libraries. Lack of pivot points, all-in-one package, and complete ignorance of social aspects (different authors versioning models, fork support, correct dealing with multiple sources). Try maintain fork, package it, and publish? And it is still should be distinguish, but it is incorrect to give other id. All-in-one targets gives another issues. Etc...

Technically now .dnx/packages folder did not ready to get deal with anything other. Version references in projects probably too.

Even while almost everything addressed to nuget, this problems /probably/ will be solved sometime, issue adressed to DNX and it's nuget relation.

Something similar happens with project.json. It is great, but oversimplied and did not work for simple cases. Default compileBuiltins it is something strange. Lot of peoples always explicitly define files. Possible? Yes. After looking in source, and reset all builtins in project.json. I mean that it is common case. Easier specify standard patterns, but not reset some implict variables (who know what else will be added?). So while it is used as build system - it is easy to replace, but while them can be 'runned' - it is no more clear. Output folder, BTW, configures partially, what did not allow get desired final layout. And default 'artifacts' name is good, but 'out' and 'build' is very common too.

So generally, to be universal tool:

  1. Will be nice to have ability to support parallel package managers. Better if manager installed via nuget itself, I.e. not part of DNX distribution.
  2. Way to switch to other build system, but keep common flavor (everything is package, ability to run directories, source running).

Any chances in long-term to achieve this? Or high-level vision is locked to described things, and no have sense even think about?

@aspnet-hello
Copy link

This issue is being closed because it has not been updated in 3 months.

We apologize if this causes any inconvenience. We ask that if you are still encountering this issue, please log a new issue with updated information and we will investigate.

@davidalpert
Copy link

davidalpert commented Dec 31, 2017 via email

@davidalpert
Copy link

davidalpert commented Dec 31, 2017 via email

@ghost ghost locked as resolved and limited conversation to collaborators Jun 1, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants