The situation:
I have a Swift Package, call it lib. lib lives in its own repository. In lib's repository, there are a bunch of local Packages; that is, these are packages that are defined, in lib, using the local-path dependency format, .package(path: "CursorPackage"), and whatnot.
All of this is fine as long as I'm locally importing lib into my actual application repository. The moment I try to import lib into my repo using SPM's remote options, which is obviously the way to go for doing things with CI, it throws the following error:
invalidManifestFormat("'CursorPackage' is not a valid path for path-based dependencies; use relative or absolute path instead.")
This error persists whether I use CursorPackage or ./CursorPackage. Obviously I don't want to try to use an absolute path, because I'm on CI, so that would involve either hard-coding things or ingesting an environment variable somehow that contains PWD.
What am I missing? This seems like it should just work. Is this just a bug in SPM that I should be reporting to Apple?
This isn't intended to be possible. If you look at the 5th bullet in the Proposed Solution section of the local packages proposal (https://github.com/apple/swift-evolution/blob/main/proposals/0201-package-manager-local-dependencies.md) it says that it's not intended for a remote package to be allowed to depend on a local package.
I expect its because there's the possibility that you could have both a versioned package with a given name and a local package with the same name; if so how would SPM resolve the conflict?
It is unfortunate though since allowing this would allow for more options in how people organize their packages, I agree.
Related
Swift Pacakage Manager allows a package manifest (Package.swift) file to specify build settings for targets.
As a security measure, some build settings can only be specified using "unsafeFlags" parameter. For example, specifying a framework search path outside the current directory using the -F build flag is considered "unsafe" because it could lead to code execution outside the package's own directory.
For packages downloaded from the internet, this could be considered an undesirable behavior. However, for locally-declared packages, this could be what we want to do.
However the design of SPM is such that any package that uses "unsafeFlags" cannot be depended on by another package.
Is there any override for this, for example, if we want to use unsafeFlags somewhere in a dependency structure of various locally-declared Swift packages?
Like, is there a setting we can supply for a package, framework, or app, so that it's allowed to depend on packages that use "unsafeFlags"?
Swift Package Manager allows unsafeOptions for dependencies specified by a commit hash. They're not allowed for versioned dependencies.
Example here.
I have build a nuget package at published it to a nuget.server site. But when I try to use the package form the server the .targets file from build folder is not in the file. But if I use the package from a local folder it works as it should. How do I get it to work ?
If i look in the package in the folder on the server it looks ok.
It's not clear to me if you mean using (referencing and restoring) a package, or building (packing) a package.
If the problem is with packing the nupkg, NuGet requires the props and targets files to have specific filenames in specific folders, but if you got it to work at least once, you probably already know that. If this is not the problem with packing, you need to give us more information because not using the correct filename convention is the most common problem and I can't guess what else the problem could be. In particular, if the package is being packed differently on your local machine compared to when it is packed on the server, it means there is something different between how you pack on the two computers, so we need more information about how the build and pack work with your project.
If the problem is with using (restoring) the package, there are a few possibilities. My best guess is that you once had a package without the targets file working correctly, and you restored the package on the server. By design, NuGet packages are immutable which means it's invalid for the contents of a package (same ID and version) to change. This allows NuGet to download the package from a remote feed once, save it in the global package folder (not a cache; they never expire) and the next time NuGet needs to restore the same package (id + version) it uses the one in the global package folder, it does not download again. This means if you once built a bad nupkg and restored it on a machine, then fix the nupkg and kept the same version number, that machine will never get the fixed nupkg. You need to delete it from the global packages folder. I'm not 100% sure, but I think if you have a local file feed and you restore a project that uses packages.config, the nupkg does not get saved in the global packages folder, so doesn't have the same problem. In short, I think the problem is that you changed the nupkg contents once without changing the version number, and one of the machines has the old copy in its global packages folder that it keeps using.
If that's not the problem, the next most likely cause is that the nupkg on the server feed has different contents to the nupkg in the local feed. I've never used NuGet.Server, but some nuget respositories (like nuget.org) do not allow overwriting nupkgs. So, if you pushed a nupkg to your server, fixed a problem in your nupkg without changing the version, then tried to push again, the second push might have failed.
In summary, your question doesn't provide enough information for us to help you, but I wrote about the most common issues above. If it doesn't help, you need to provide us with more information. An example of the problem is the best way to give us enough information to help you.
I'm developing a library of components, which is using Lerna. This means each component directory has a package.json file. I also have a dist in each of them. That's where the bundle yields to, obviously. My issue occurs while developing. My import statements encounter the package.json and try to get the source from dist instead of an index.js, where the source lives. How can I mitigate that so the require process avoids the package.json?
Ok, apparently I found my answer in Webpack docs, but it wasn't that easy. You have to add a module key (in addition to main) to let the Webpack resolver know which source to load while in modules environment (development).
See here: https://webpack.js.org/configuration/resolve/#resolve-mainfields
I'm very new to Golang. I see that in Golang you can import packages directly from Github like:
import "github.com/MakeNowJust/heredoc"
Does that mean I have to remember this URL in order to use this package? IMHO this is not cool. What if later the author of the package removed it or changed the URL? Any ideas?
I would recommend you to read the How to Write Go Code documentation and this blog post.
The path you're seeing in your import line is not a url, but only the path the package is located in (normally relative to $GOROOT/src/pkg or $GOPATH/src). So your package heredoc is most probably located in the directory $GOPATH/src/github.com/MakeNowJust/heredoc.
The recommended way to use external packages is by downloading and installing them via go get. You might want to check out the documentation of go get by go get --help.
The path that import statement refers is just appended to $GOPATH/src. So that import statement basically says "import the package located at $GOPATH/src/github.com/MakeNowJust/heredoc"
What if later the author of the package removed it or changed the URL?
As long as you already have the source files for that package at the expected location, it should be included even if the repo has moved.
dont worry man! you can use glide tool for package management
How does one do a relative import from a parent directory?
From meme/cmd/meme:
import "../../../meme"
This gives an ambiguous error:
matt#stanley:~/gopath/src/bitbucket.org/anacrolix/meme/cmd/meme$ go get bitbucket.org/anacrolix/meme/cmd/meme
can't load package: /home/matt/gopath/src/bitbucket.org/anacrolix/meme/cmd/meme/main.go:8:2: local import "../../../meme" in non-local package
matt#stanley:~/gopath/src/bitbucket.org/anacrolix/meme/cmd/meme$ echo $GOPATH
/home/matt/gopath
How do I import locally from a parent directory?
Edit: Relative import paths are not the way to go in Go. Lack of documentation shows something about popularity of relative paths, and I don't see a reason for using them. Go's recommended code organization works pretty well. Every package should have a unique import path and be imported everywhere using that same import path.
See how a package like github.com/ha/doozerd/peer imports its neighbors. This is a common practice among Go projects and I've seen it a lot of times. Package camlistore.org/pkg/auth (also on GitHub; written by one of the main authors of Go) imports camlistore.org/pkg/netutil by full path.
Even if you are having both commands and libraries in the same project this approach works. In your original questions you wisely asked for best practices. I did my best in explaining best practices on this matter.
Import paths can't be relative in Go. I recommend reading How to Write Go Code, the essential reading on organizing Go projects. Here's a short overview:
Make a directory like ~/go for your Go development. Then say:
$ export GOPATH=~/go
$ mkdir $GOPATH/{src,bin,pkg}
$GOPATH/src holds source code for all your Go packages, even the ones your download with go get. bin and pkg keep output of compilations. Packages with package name main are commands and yield to executable binaries which go to $GOPATH/bin. Other packages are libraries and their compiled object files are put in $GOPATH/pkg.
Now if you put your code in $GOPATH/src/matt/meme, you can import it by import "matt/meme". It's recommended to use a prefix for your package names and leave short package names for standard libraries. That's why I used $GOPATH/src/matt/meme instead of $GOPATH/src/meme.
Organize your code around this idea.
Thanks for adding to your question. First, an answer, then some explanation. I built your code by,
go get, just as you had it. (I ignored the error messages.)
setting the import line in main.go back to "../../../meme", as you wanted to do.
(commenting out a little bit of code containing an unused variable.)
then in the meme/cmd/meme directory, either go run main.go or go build main.go worked.
I was wrong in my comment earlier when I said go install works; I should have said go build.
The key however is that go build alone does not work; you must type go build main.go. This is because the go command does not allow "local imports in non-local packages." You are right that spec is of little help here. It weasels out saying, "The interpretation of the ImportPath is implementation-dependent." The current implementation behavior was set with CL 5787055, which was subsequently debated at length on Go-nuts.
"Local" means indicated with a file system relative path. Obviously a relative path starting with .. is local, so the trick is just getting the go command to treat main as a local package as well. It apparently doesn't do this when you type go build, but does when you type go build main.go.
Relarive imports are supported when manually using the compiler, linker, ... directly. The 'go' (build) tool doesn't support the same (somehow comparable to eg Java).
This may not answer the original question, but I was trying to do the above when I didn't really need to, all I needed to do was update go.mod temporarily with a replace :
module github.com/pselle/foo
replace github.com/pselle/bar => /Users/pselle/Projects/bar
require (
github.com/pselle/bar v1.0.0
)
reference:
https://thewebivore.com/using-replace-in-go-mod-to-point-to-your-local-module/