search

whyrusleeping / gx

A package management tool
MIT License
1.88k stars 111 forks source link

Extend the `Package` structure #193

Open schomatis opened 5 years ago

schomatis commented 5 years ago

To not only contain the package.json information (how to call that? package definition?) but also other working details, like the package directory, that conceptually are very close to the package definition. The question is whether to rename it or extend it in a separate structure.

Stebalien commented 5 years ago

FYI: https://github.com/whyrusleeping/gx/issues/145#issuecomment-343038895

However, I definitely would not include "working details" like the package directory.

You should also check out https://github.com/whyrusleeping/gx/issues/179#issuecomment-408243162

The plan (at least the last time I discussed this with Why) was to make gx into a lock file manager and rely on language specific package managers for everything else. This'll give us what we want (dependable package "vendoring" without duplication) without antagonizing the rest of the go world.

schomatis commented 5 years ago

Thanks for the references.

Just to clarify, I don't mean including the directory inside the package.json, but some functions I'm seeing in the code carry the Package structure and alongside the string with the path where it's installing it. I wanted to consolidate those two in a coherent structure (that may or may not be Package). That is, I simply plan to restructure some internal parts of the gx/gx-go repos, but most definitely not change API or how it's designed (that's something that should be discussed in the issues you're pointing to).

Stebalien commented 5 years ago

Ah. I see. Yes, I agree.