Support for 3rd party package managers #61

Closed
Horusiath opened this Issue Sep 7, 2014 · 5 comments

Comments

Projects
None yet
4 participants
@Horusiath

I've noticed that Packet offers a lot nicer and more useful way do manage project dependencies than what NuGet provides, I would like to be able to use it with other package managers.

Example: When you want to provide support web-oriented projects with many client-side libraries, you may still rely on NuGet, but from my own experience bower and npm are much richer in this matter.

So my question is - are you guys thinking about providing layer for third party package managers?

@agross

This comment has been minimized.

Show comment
Hide comment
@agross

agross Sep 7, 2014

Contributor

Hm, I don't see a point in replicating bower and npm, especially given that they appear to have the same features as Paket (e.g. pessimistic version constraints). Why not just use them when you want to install "their" packages? VS.next does the same.

Contributor

agross commented Sep 7, 2014

Hm, I don't see a point in replicating bower and npm, especially given that they appear to have the same features as Paket (e.g. pessimistic version constraints). Why not just use them when you want to install "their" packages? VS.next does the same.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 7, 2014

Member

Actually we plan to support different package sources, but we didn't plan
which yet. Why do you think npm would be needed?
On Sep 7, 2014 2:19 PM, "Alexander Groß" notifications@github.com wrote:

Hm, I don't see a point in replicating bower and npm, especially given
that they appear to have the same features as Paket (e.g. pessimistic
version constraints). Why not just use them when you want to install
"their" packages? VS.next does the same
http://www.hanselman.com/blog/IntroducingGulpGruntBowerAndNpmSupportForVisualStudio.aspx
.


Reply to this email directly or view it on GitHub
#61 (comment).

Member

forki commented Sep 7, 2014

Actually we plan to support different package sources, but we didn't plan
which yet. Why do you think npm would be needed?
On Sep 7, 2014 2:19 PM, "Alexander Groß" notifications@github.com wrote:

Hm, I don't see a point in replicating bower and npm, especially given
that they appear to have the same features as Paket (e.g. pessimistic
version constraints). Why not just use them when you want to install
"their" packages? VS.next does the same
http://www.hanselman.com/blog/IntroducingGulpGruntBowerAndNpmSupportForVisualStudio.aspx
.


Reply to this email directly or view it on GitHub
#61 (comment).

@forki forki added the question label Sep 8, 2014

@Horusiath

This comment has been minimized.

Show comment
Hide comment
@Horusiath

Horusiath Sep 8, 2014

@forki npm came to my mind, since it has an excellent support for client side MV* frameworks, especially AngularJS - for example yeoman scaffold generators (and yeoman itself) as well as both testing runtimes Karma and Protractor are distributed as npm packages.

@agross From my point of view Paket could be potentially used as abstraction layer above various package managers - one manager to rule them all. If it only purpose was to fix NuGet, then simple fork (NuGet++) would be a better solution.

@forki npm came to my mind, since it has an excellent support for client side MV* frameworks, especially AngularJS - for example yeoman scaffold generators (and yeoman itself) as well as both testing runtimes Karma and Protractor are distributed as npm packages.

@agross From my point of view Paket could be potentially used as abstraction layer above various package managers - one manager to rule them all. If it only purpose was to fix NuGet, then simple fork (NuGet++) would be a better solution.

@agross

This comment has been minimized.

Show comment
Hide comment
@agross

agross Sep 8, 2014

Contributor

Hm, I don't see a point in reinventing other wheels. One to rule them all would likely result in an abstraction that's less usable and flexible than the things we're trying abstract in the first place.

Alex

Alexander Groß
Tiny phone, tiny mail

On Mon, Sep 8, 2014 at 9:27 PM, Bartosz Sypytkowski
notifications@github.com wrote:

@forki npm came to my mind, since it has an excellent support for client side MV* frameworks, especially AngularJS - for example yeoman scaffold generators (and yeoman itself) as well as both testing runtimes Karma and Protractor are distributed as npm packages.

@agross From my point of view Paket could be potentially used as abstraction layer above various package managers - one manager to rule them all. If it only purpose was to fix NuGet, then simple fork (NuGet++) would be a better solution.

Reply to this email directly or view it on GitHub:
#61 (comment)

Contributor

agross commented Sep 8, 2014

Hm, I don't see a point in reinventing other wheels. One to rule them all would likely result in an abstraction that's less usable and flexible than the things we're trying abstract in the first place.

Alex

Alexander Groß
Tiny phone, tiny mail

On Mon, Sep 8, 2014 at 9:27 PM, Bartosz Sypytkowski
notifications@github.com wrote:

@forki npm came to my mind, since it has an excellent support for client side MV* frameworks, especially AngularJS - for example yeoman scaffold generators (and yeoman itself) as well as both testing runtimes Karma and Protractor are distributed as npm packages.

@agross From my point of view Paket could be potentially used as abstraction layer above various package managers - one manager to rule them all. If it only purpose was to fix NuGet, then simple fork (NuGet++) would be a better solution.

Reply to this email directly or view it on GitHub:
#61 (comment)

@ilkerde

This comment has been minimized.

Show comment
Hide comment
@ilkerde

ilkerde Sep 11, 2014

Contributor

My proposal ist to answer this question with No for the time being. @agross Move to FAQ and close?

Contributor

ilkerde commented Sep 11, 2014

My proposal ist to answer this question with No for the time being. @agross Move to FAQ and close?

@agross agross closed this in 558e30f Sep 13, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment