8 ms·

Hi! The response to your fears are in the announcement. "If you want to download dependencies alongside project code instead of using a global cache, use the $D

Hi! The response to your fears are in the announcement. "If you want to download dependencies alongside project code instead of using a global cache, use the $DENO_DIR env variable." Then, it will work like node_modules.

fermienrico 6y ago
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
  - ric2b 6y ago
    It could be a good idea if they were immutable, like IPFS links.
bgdam 6y ago
Ah, in this case, I would then have to commit my dependencies into my VCS to maintain reproducible builds. I'm not sure I like that solution very much either. I've seen node_modules in multiple GBs, and I'm sure Deno's dependency sizes are going to be similar.
- nitsky 6y ago
  In practice modules will be available from sources that will have similar reliability to npm: github.com, unpkg.com, cdn.pika.dev, jspm.io, etc.
  - bgdam 6y ago
    Which then raises the question - how is it better than NPM? If there are going to be centralized repositories (like NPM), and if I have to download my dependencies into a $DENO_DIR (like NPM), and if I am then loading these dependencies from local files (like NPM), how is it any different to NPM? Except for being less secure by default? This is starting to look like a case of being different just so you can say you're different.
    - austincheney 6y ago
      NPM is a dependency management failure which is why you are ending up with hundreds of dependencies in the first place. It sounds like you want to reproduce that insanity in Deno. Deno is set up in such a way to dissuade you from the stupidity by default but allow it in very few steps if you cannot imagine a world without it. In my opinion this is Deno’s biggest selling point.
      - bgdam 6y ago
        > Deno is set up in such a way to dissuade you from the stupidity by default but allow it in very few steps if you cannot imagine a world without it. Could you elaborate on this? Is it that Deno is against the whole 'small packages that do one thing well' principle and instead in favor of complete libaries? How exactly would it dissuade me from installing hundreds of dependencies?
thayne 6y ago
That might work for some projects, but can quickly blow up the size of the repo. I don't think it it is an unsolvable problem. For example, other solutions could be using a mirror proxy to get packages, instead of directly from the source, or pre-populating the deno dir from an artifact store. It would be nice to have documentation on how to do those though.
- s17n 6y ago
  A better solution is something like https://vfsforgit.org/ https://vfsforgit.org/
  - thayne 6y ago
    That's not necessarily better. For one thing, it doesn't support Linux yet. For another, afaik, Azure DevOps is the only git hosting service that supports it. Even if it was better supported, I wouldn't want to start using it just so I can include all my dependencies in git. Of course if you are using something like vfs for git anyway, then increasing the repo size is less of an issue. It still feels wrong to me though.
    - s17n 6y ago
      Yeah, I'm not really advocating the use of GVFS specifically, but what I am saying is that once you've lived in a world where all your dependencies are in your repo you won't want to go back, and that Git should improve their support for large repos (in addition to checking in all our dependencies, we should be able to check in all our static assets).

fermienrico 6y ago

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
- ric2b 6y ago
  It could be a good idea if they were immutable, like IPFS links.

bgdam 6y ago

Ah, in this case, I would then have to commit my dependencies into my VCS to maintain reproducible builds. I'm not sure I like that solution very much either. I've seen node_modules in multiple GBs, and I'm sure Deno's dependency sizes are going to be similar.

nitsky 6y ago
In practice modules will be available from sources that will have similar reliability to npm: github.com, unpkg.com, cdn.pika.dev, jspm.io, etc.
- bgdam 6y ago
  Which then raises the question - how is it better than NPM? If there are going to be centralized repositories (like NPM), and if I have to download my dependencies into a $DENO_DIR (like NPM), and if I am then loading these dependencies from local files (like NPM), how is it any different to NPM? Except for being less secure by default? This is starting to look like a case of being different just so you can say you're different.
  - austincheney 6y ago
    NPM is a dependency management failure which is why you are ending up with hundreds of dependencies in the first place. It sounds like you want to reproduce that insanity in Deno. Deno is set up in such a way to dissuade you from the stupidity by default but allow it in very few steps if you cannot imagine a world without it. In my opinion this is Deno’s biggest selling point.
    - bgdam 6y ago
      > Deno is set up in such a way to dissuade you from the stupidity by default but allow it in very few steps if you cannot imagine a world without it. Could you elaborate on this? Is it that Deno is against the whole 'small packages that do one thing well' principle and instead in favor of complete libaries? How exactly would it dissuade me from installing hundreds of dependencies?

thayne 6y ago

That might work for some projects, but can quickly blow up the size of the repo. I don't think it it is an unsolvable problem. For example, other solutions could be using a mirror proxy to get packages, instead of directly from the source, or pre-populating the deno dir from an artifact store. It would be nice to have documentation on how to do those though.

s17n 6y ago
A better solution is something like https://vfsforgit.org/ https://vfsforgit.org/
- thayne 6y ago
  That's not necessarily better. For one thing, it doesn't support Linux yet. For another, afaik, Azure DevOps is the only git hosting service that supports it. Even if it was better supported, I wouldn't want to start using it just so I can include all my dependencies in git. Of course if you are using something like vfs for git anyway, then increasing the repo size is less of an issue. It still feels wrong to me though.
  - s17n 6y ago
    Yeah, I'm not really advocating the use of GVFS specifically, but what I am saying is that once you've lived in a world where all your dependencies are in your repo you won't want to go back, and that Git should improve their support for large repos (in addition to checking in all our dependencies, we should be able to check in all our static assets).