You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, it seems that depexts is designed only to handle system packages, and an algorithm is used to decide a single system package manager (where the decision is stored as os-distribution.)
Yet there are some software in the wild that are not distributed (at least not normally and/or officially) using system package managers. A few examples include sass, typescript, yarn, next whose main distribution channel is through npm.
Also, package management systems like npm (for the Node.js ecosystem) and pip (for the Python ecosystem) usually live in parallel with the system package management system. Therefore, it makes at least some sense to support both of them.
I have created a proof-of-concept PR #5690 to demonstrate how making a strict extension to the current depexts system could bring support for those (usually) language-specific package management systems that are by design to be used in parallel to the system package manager. A concrete motivation is also listed in the PR.
The design is to add a special and namespaced type of depexts package name spec, e.g., @npm:pkgname, @pip:pkgname, etc. As experimented in #5690, this can be done without adding too much complexity to the existing depexts layer.
Critics and comments are much welcomed. Also, please point out anything I have mistaken and/or stupid assumptions that I may have made.
The text was updated successfully, but these errors were encountered:
Currently, it seems that depexts is designed only to handle system packages, and an algorithm is used to decide a single system package manager (where the decision is stored as
os-distribution
.)Yet there are some software in the wild that are not distributed (at least not normally and/or officially) using system package managers. A few examples include
sass
,typescript
,yarn
,next
whose main distribution channel is through npm.Also, package management systems like npm (for the Node.js ecosystem) and pip (for the Python ecosystem) usually live in parallel with the system package management system. Therefore, it makes at least some sense to support both of them.
I have created a proof-of-concept PR #5690 to demonstrate how making a strict extension to the current depexts system could bring support for those (usually) language-specific package management systems that are by design to be used in parallel to the system package manager. A concrete motivation is also listed in the PR.
The design is to add a special and namespaced type of depexts package name spec, e.g.,
@npm:pkgname
,@pip:pkgname
, etc. As experimented in #5690, this can be done without adding too much complexity to the existing depexts layer.Critics and comments are much welcomed. Also, please point out anything I have mistaken and/or stupid assumptions that I may have made.
The text was updated successfully, but these errors were encountered: