5 ms·

Off topic: is there still no alternative for putting random URLs directly in a source code in order to use some libs?

• maerF0x0 5y ago
  what do you mean by "random urls"?
  • politician 5y ago
    They are confused about import notation.
  • stackedinserter 5y ago
    Having `import "github.com/liyue201/gostl/ds/array"` in codebase looks weird and unsafe. Like, who's liyue201 and what exactly I'm importing? Vendoring helps a bit, but it's still ugly. Same problems exist in other languages, although "import numpy as np" doesn't explicitly say that you're importing a random head from someone's master.
    • lokar 5y ago
      You could setup your build to vendor. The import would be the same.
    • kortex 5y ago
      > Same problems exist in other languages, although "import numpy as np" doesn't explicitly say that you're importing a random head from someone's master. Sure, python is just implicitly doing so, is that any better? Lets say you know nothing about python or numpy. You see "import numpy". What/who is numpy? How is it provisioned? Is there only one thing called numpy? How do you know it's installed locally/site-packages/editable/PYTHONPATH? You can answer these questions, but not immediately. Numpy is a poor example because it's so well know, but the other day I was trying to sort out "from pylab import *". Can't "pip install pylab". Turns out, matplotlib provides it, but for weird legacy reasons, pylab is a top level namespace. The whole point is, if you don't trust "liyue201", then you can immediately know not to import that package. It's completely explicit in what it's doing, and no one is making you install libs from github.
    • tikkabhuna 5y ago
      Great thing about the import notation is it points you in the direction to look. Where’s the numpy code base? Your go.mod should specify the version of the library you’re using.
    • cuteboy19 5y ago
      It's not much different from import com.mysql.cj.jdbc
      • exdsq 5y ago
        I’ve never thought about that but yeah you’re right, that’s cool. I’m not a fan of Go’s imports either but this makes it make a little more sense to me.
    • mseepgood 5y ago
      > explicitly say that you're importing a random head from someone's master You don't import HEAD from master. Do you even understand how go.mod, go.sum and the checksum database work?
    • jen20 5y ago
      Frankly if it imparts that kind of concern, that is the dependency system working properly. ‘require “leftpad”’ may look safer, but is in fact not, and unless you happen to know what is in the standard library of Node.js off the top of your head, provides not so much as a clue that the library is even third party.
    • DelightOne 5y ago
      What namespacing do you envision? On the one side you don't like short names that are installed locally and on the other you seem to not like the full url noting where to retrieve the library.
    • qbasic_forever 5y ago
      On the contrary, I absolutely want to quickly and easily know if my corporate codebase is depending on github/<random user>. Golang has a pretty solid standard library and process to extend it. The 'x' packages are all reasonably vetted and close to official libraries: https://pkg.go.dev/golang.org/x https://pkg.go.dev/golang.org/x You could easily make a decree in a codebase that you won't depend on random github code and only use stuff from trusted sources like standard library, x, etc.
• bsdnoob 5y ago
  You can use replace directive in go mod then you'd be able to load library from local path
• evanmoran 5y ago
  This is how imports work in go. You make it look like a url, but then can choose in the mod (the module) file if it is local or to keep the url. This makes it quite clean because files have the same import url even as relative paths change, so you can move files all around and the import statements can stay the same. It also has the added advantage that there is no single module repository like in npm. So any url / GitHub repo works so no module can permanently own a name.
  • tsimionescu 5y ago
    > This makes it quite clean because files have the same import url even as relative paths change, so you can move files all around and the import statements can stay the same. That only works if no one is using your module as a dependency. > So any url / GitHub repo works so no module can permanently own a name. Only if go mod understands the source control mechanism, and only if the HTTP server in front of that speaks the survival go mod protocol. It's a horrible system that the go team doesn't use internally.
    • icholy 5y ago
      Why do you have such strong opinions on things you clearly don't use or understand?
      • tsimionescu 5y ago
        I do use and understand these things. I have fought several times with go mod and know a few of its quirks. Go mod works by cloning the remote repository you import (unless the module it is working on has a replace directive). It does this via HTTPS or Git ssh or other source control mechanisms, based on the form of the import link and your GOPROXY and GOPRIVATE environment variables and their various flags and options. For each source control mechanism, it has some specific way to decide exactly what version to sync to (such as git tags to chose a specific commit). It also depends on how you have configured your source control in your local environment, as that is what will ultimately download the code - if you want to download modules from repos that require various forms of authentication, it's up to every dev to configure credentials for each of these (or theoretically someone could mirror them to a single repo with common auth). It's still important to note that replace directives are only used when building that particular module. Say module A depends on module B. Module B has a dependency on module github.com/proj/C, but locally adds a replace directive to replace github.com/proj/C with bitbucket.com/proj/C. When running go mod in B's folder, it will download the version of C from BitBucket. But, when building module A, it will download module C from GitHub. Replace directives are just for local builds, your dependents don't look at them.
• mseepgood 5y ago
  It's not random. It's what you as a developer wanted as a dependency, and it's cryptographically pinned to the exact version you wanted.