4 ms·

I think the primary way to manage dependencies should be in a local DIR and optionally, a URL can be specified. The default in Deno is questionable choice. Jus

I think the primary way to manage dependencies should be in a local DIR and optionally, a URL can be specified. The default in Deno is questionable choice. Just don't fuck with what works. Default should be safest followed by developers optionally enabling less safe behaviors.

fiddlerwoaroof 6y ago
Using a universally unique identifier like a URL is a good idea: this way, https://foo.com/foo https://foo.com/foo and https://bar.com/foo https://bar.com/foo are distinct and anyone who can register their own name gets a namespace, without relying on yet another centralized map of names->resources. After all, the whole point of a URL is that it unambiguously identifies resources in a system-independent way.
- littlestymaar 6y ago
  Good luck finding which of foo.com/foo or bar.com/foo is the foo module you want though…
  - janpot 6y ago
    Good luck finding which of google.com/search or bing.com/search is the search engine you want though
    - littlestymaar 6y ago
      This is true actually, and that's why being the default search engine is so important Google pays billions each year for that.
- fermienrico 6y ago
  No one is questioning the utility of URLs. Using URLs to specify dependencies right in the import statement is a horrible idea.
  - fiddlerwoaroof 6y ago
    How is it any worse than using names from a namespace controlled by “npmjs.com”: if you’re concerned about build stability, you should be caching your deps on your build servers anyways.
    - fermienrico 6y ago
      I've never used npm or developed any javascript before but it sounds equally horrible. Not decoupling the source of the package (i.e., the location of the repository whether it is on remote or local) and its usage in the language is a terrible idea. from foo import bar # foo should not be a URL. It should just be an identifier. # The location of the library should not be mangled up in the code base. Are we gonna search replace URL strings in the entire codebase because the source changed? Can someone tell me what is the upside of this approach because I cannot see a single one but many downsides.
      - fiddlerwoaroof 6y ago
        The whole idea of a URL is that it’s a standardized way of identifying resources in a universally unique fashion: if I call my utility library “utils”, I’m vulnerable to name collisions when my code is run in a context that puts someone else’s “utils” module ahead of mine on the search path. If my utility module is https://fwoar.co/utils https://fwoar.co/utils then, as long as I control that domain, the import is unambiguous (especially if it includes a version or similar.). The issue you bring up can be solved in several ways: for example, xml solves it by allowing you to define local aliases for a namespace in the document that’s being processed. Npm already sort of uses the package.json for this purpose: the main difference is that npmjs.com hosts a centralized registry of module names, rather than embedding the mapping of local aliases->url in the package.json
        fermienrico 6y ago
        Allow me to provide an extremely relevant example (medium sized code base). About 100 python files, each one approximately 500-1000 lines long. Imagine in each one of these files, there are 10 unique imports. If they are URLs (with version encoded in the URL): - How are you going to pin the dependencies? - How do you know 100 files are using the same exact version of the library? - How are you going to refactor dependency resolution or upgrades, maintenance, deprecation? How will these problems be solved? Yes, I understand the benefits of the URL - its a unique identifier. You need an intermediate "look up" table to decouple the source from the codebase. That's usually requirements.txt, poetry.lock, pipenv.lock, etc.
- ric2b 6y ago
  It could be a good idea if they were immutable, like IPFS links.

fiddlerwoaroof 6y ago

Using a universally unique identifier like a URL is a good idea: this way, https://foo.com/foo https://foo.com/foo and https://bar.com/foo https://bar.com/foo are distinct and anyone who can register their own name gets a namespace, without relying on yet another centralized map of names->resources. After all, the whole point of a URL is that it unambiguously identifies resources in a system-independent way.

littlestymaar 6y ago
Good luck finding which of foo.com/foo or bar.com/foo is the foo module you want though…
- janpot 6y ago
  Good luck finding which of google.com/search or bing.com/search is the search engine you want though
  - littlestymaar 6y ago
    This is true actually, and that's why being the default search engine is so important Google pays billions each year for that.
fermienrico 6y ago
No one is questioning the utility of URLs. Using URLs to specify dependencies right in the import statement is a horrible idea.
- fiddlerwoaroof 6y ago
  How is it any worse than using names from a namespace controlled by “npmjs.com”: if you’re concerned about build stability, you should be caching your deps on your build servers anyways.
  - fermienrico 6y ago
    I've never used npm or developed any javascript before but it sounds equally horrible. Not decoupling the source of the package (i.e., the location of the repository whether it is on remote or local) and its usage in the language is a terrible idea. from foo import bar # foo should not be a URL. It should just be an identifier. # The location of the library should not be mangled up in the code base. Are we gonna search replace URL strings in the entire codebase because the source changed? Can someone tell me what is the upside of this approach because I cannot see a single one but many downsides.
    - fiddlerwoaroof 6y ago
      The whole idea of a URL is that it’s a standardized way of identifying resources in a universally unique fashion: if I call my utility library “utils”, I’m vulnerable to name collisions when my code is run in a context that puts someone else’s “utils” module ahead of mine on the search path. If my utility module is https://fwoar.co/utils https://fwoar.co/utils then, as long as I control that domain, the import is unambiguous (especially if it includes a version or similar.). The issue you bring up can be solved in several ways: for example, xml solves it by allowing you to define local aliases for a namespace in the document that’s being processed. Npm already sort of uses the package.json for this purpose: the main difference is that npmjs.com hosts a centralized registry of module names, rather than embedding the mapping of local aliases->url in the package.json
      - fermienrico 6y ago
        Allow me to provide an extremely relevant example (medium sized code base). About 100 python files, each one approximately 500-1000 lines long. Imagine in each one of these files, there are 10 unique imports. If they are URLs (with version encoded in the URL): - How are you going to pin the dependencies? - How do you know 100 files are using the same exact version of the library? - How are you going to refactor dependency resolution or upgrades, maintenance, deprecation? How will these problems be solved? Yes, I understand the benefits of the URL - its a unique identifier. You need an intermediate "look up" table to decouple the source from the codebase. That's usually requirements.txt, poetry.lock, pipenv.lock, etc.
ric2b 6y ago
It could be a good idea if they were immutable, like IPFS links.