The location: github.com/elastic/beats
The mod file: github.com/elastic/beats/go.mod
The module name: github.com/elastic/beats/v7
The tag: v7.10.2
What LoTR incantation of go get to I have to run to get a little dependency update action?
This will update to latest minor.patch version of v7:
go get github.com/elastic/beats/v7
or if you want a specific version to update/downgrade to:
go get github.com/elastic/beats/v7#v7.10.2
Adding the -u flag will additionally update the dependencies of github.com/elastic/beats/v7:
go get -u github.com/elastic/beats/v7
The argument list passed to go get should generally be a list of package paths or patterns, not just a module path.
For example, you might invoke:
go get -d github.com/elastic/beats/v7/libbeat/beat#latest
in order to obtain the latest version of package …/libbeat/beat and also download any transitive dependencies needed for that package.
(You can pass just a module path, and that should also update the version of the dependency module overall, but it will not download source code or module checksums for transitive dependencies that may be needed in order to build the updated package. go get does not in general know which transitive dependencies will be relevant to the commands that you plan to invoke after it, and it does not do extra work to speculatively identify relevant dependencies.)
I have a go.mod looks like
require(
...
github.com/google/wire v0.3.1-0.20190716160000-66f78fc84606
...
)
Based on my understanding, if a package looks like that (yyyymmddMMSS-commit_id), which version should be v0.0.0 but not v0.3.1 as this example.
Could someone guide me how should I explain this? Does go mod ignore the v0.3.1- prefix?
It's the result of go get'ing a specific commit that exists in the tree after a semantic version tag:
go get github.com/google/wire#66f78fc84606
Pseudo versions are used not only when there is no version tag.
As the official documentation about pseudo versions shows:
Pseudo-versions may refer to revisions for which no semantic version tags are available. They may be used to test commits before creating version tags, for example, on a development branch.
...
vX.Y.(Z+1)-0.yyyymmddhhmmss-abcdefabcdef is used when the base version is a release version like vX.Y.Z.
In this case, the repository does have semantic version tags. The base version here is v0.3.0, and by getting a specific commit (66f78fc84606) that exists after v0.3.0 and before the next one v0.4.0, you end up with:
github.com/google/wire v0.3.1-0.20190716160000-66f78fc84606
In fact there are 3 acceptable forms of pseudo-version:
vX.0.0-yyyymmddhhmmss-abcdefxyz.
when no earlier versioned commit with an appropriate major version before target commit
vX.Y.Z-pre.0.yyyymmddhhmmss-abcdefxyz
when most recent versioned commit before the target commit is vX.Y.Z-pre
vX.Y.(Z+1)-0.yyyymmddhhmmss-abcdefxyz
when most recent versioned commit before the target commit is vX.Y.Z
Some more details about Managing Go Module Pseudo-Versions:
https://hackernoon.com/managing-go-module-pseudo-versions-in-go-113-412h30lw
I'm running Xcode 11 Beta 4.
I'm using CocoaPods, and wanted to use one of my dependencies with Swift Package Manager as a static library instead of as a framework.
On a fresh project created with Xcode 11, the dependency can be imported successfully, but on my existing CocoaPods workspace, it does not.
I think it's likely related, but I'm also getting this link warning in Xcode:
directory not found for option '-L/Users/username/Library/Developer/Xcode/DerivedData/App-axanznliwntexmdfdskitsxlfypz/Build/Products/Release-iphoneos
I went to see if the directory exists after the warning is emitted, and it does.
I could not find any meaningful difference between the newly-created project and my old one, other than the existence of CocoaPods.
Would appreciate any pointers.
After adding a library (FASwiftUI in my case) through Swift Package Manager I had to add it to
Project Settings -> My Target ->
General -> Frameworks, Libraries, and Embedded Content
to be visible in the import statement.
I did not add any scripts for it to work.
Based on #AlexandreMorgado answer it seems like it is better to run this script in Build phases before Compile Sources. Then it works when archiving.
if [ -d "${SYMROOT}/Release${EFFECTIVE_PLATFORM_NAME}/" ] && [ "${SYMROOT}/Release${EFFECTIVE_PLATFORM_NAME}/" != "${SYMROOT}/${CONFIGURATION}${EFFECTIVE_PLATFORM_NAME}/" ]
then
cp -f -R "${SYMROOT}/Release${EFFECTIVE_PLATFORM_NAME}/" "${SYMROOT}/${CONFIGURATION}${EFFECTIVE_PLATFORM_NAME}/"
fi
Solution
let package = Package(
name: "PackageName",
dependencies: [
// YOU MUST ADD THE DEPENDENCY BOTH HERE [1] AND BELOW [2]
.package(url: "https://github.com/mattmaddux/FASwiftUI", from: "1.0.4")
],
targets: [
.target(
name: "PackageName",
/*[2]*/ dependencies: ["FASwiftUI"], // [2] <<<--------- Added here as well
]
)
Explanation
I'm developing a Swift package that must provide FontAwesome Icons to whoever imports it.
I was getting "No such module 'FASwiftUI'" in my SwiftUI preview canvas.
I solved it by adding "FASwiftUI" to BOTH the dependencies array of the package AS WELL AS to the dependencies array in the target itself.
Full Package.swift File
// swift-tools-version:5.3
// The swift-tools-version declares the minimum version of Swift required to build this package.
import PackageDescription
let package = Package(
name: "PackageName",
platforms: [
.macOS(.v11),
.iOS(.v14)
],
products: [
// Products define the executables and libraries a package produces, and make them visible to other packages.
.library(
name: "PackageName",
targets: ["PackageName"])
],
dependencies: [
// Dependencies declare other packages that this package depends on.
.package(url: "https://github.com/nalexn/ViewInspector", from: "0.8.1"),
.package(url: "https://github.com/mattmaddux/FASwiftUI", from: "1.0.4")
],
targets: [
// Targets are the basic building blocks of a package. A target can define a module or a test suite.
// Targets can depend on other targets in this package, and on products in packages this package depends on.
.target(
name: "PackageName",
dependencies: ["FASwiftUI"], // <<<--------- Added this here
resources: [
.process("Assets")
]
),
.testTarget(
name: "PackageNameTests",
dependencies: ["PackageName", "ViewInspector"])
]
)
It turned out that Swift Package Manager implicitly depends on the project's Configuration names. I had them at live/qa instead of Release/Debug, and changing them back resolved the issue. Very odd, but I hope it saves you some trouble dear reader.
After a whole week fighting this issue, I developed a workaround using schemes and pre-actions.
I have a configuration called "Beta", so Xcode can't compile SPM dependencies. I realised Xcode compile SPM dependencies as Swift modules and add the files in Build/Products/Release-iphoneos folder in DeriverData.
So I created a scheme in Xcode and added this run script on build pre-actions:
cp -f -R "${SYMROOT}/Release${EFFECTIVE_PLATFORM_NAME}/" "${SYMROOT}/${CONFIGURATION}${EFFECTIVE_PLATFORM_NAME}/"
This script run before the build process, copying files and modules generated by Xcode on default Release-iphoneos folder to configuration folder, Beta-iphoneos, in my case.
After coping the content from Release-iphoneos to your $configuration$-iphoneos folder Xcode should correctly compile, build and run your project.
I just ran into a similar problem and discovered that my schemes referenced old configurations, configurations that no longer existed. Once I updated them to the correct configurations the build succeeded.
(I'm leaving this comment more than a year after the original post. It's possible that what I ran into is completely different from what was originally reported. Still, it took me quite a while to track the problem down, so I wanted to leave a note that might save others time.)
Clearing the derived data solved the issue in my case. I have Microsoft Azure Devops CI Pipeline, to clear the derived data I have to edit the Xcode build task and in the "Actions" field add this command: clean.
What worked for me: I removed my import WebMIDIKit line and added it again.
Based on #sliwinski.lukas's answer, in my case the ${CONFIGURATION} was outputting "Release", so it was just copying the Release folder itself which was no good. I simply hardcoded my configuration name, and flipped Release and MyConfiguration, and it worked. I put the following code right before "Compile Sources" in the "Build Phases" tab:
cp -f -R "${SYMROOT}/MyConfiguration${EFFECTIVE_PLATFORM_NAME}/" "${SYMROOT}/Release${EFFECTIVE_PLATFORM_NAME}/" || true
Also importantly, I had to add this in the project that used the SPM and not in the main app.
I just ran into a similar problem when running xcodebuild from the command line. I was passing CONFIGURATION_BUILD_DIR=build but found that it needs to be an absolute path: CONFIGURATION_BUILD_DIR=$(pwd)/build solved the problem.
Might I shed a bit more light on your plight...
I'm working on a fairly large iOS app (6680 files) whose result is composed of many frameworks and a mixed bag of podfiles, swift packages, legacy ObjC code (that still outnumbers newer Swift stuff).
Whenever we deal with swift packages, we need to wrap them in frameworks because it simplifies podfile & dependency resolutions when we have our remote (Jenkins) build system eat everything up to spew binaries for internal QA & ultimately, Enterprise & AppStore publishing.
Earlier today, I was dealing with one such swift package wrapped in a framework and all the issues listed above hit me square in the face.
After stashing, pushing usable code and then reapplying my stashed framework wrapper to the swift package, I used a different route than opening our project's workspace where a bunch of projects and targets are collected.
Opening the lone framework wrapper seems to have kicked XCode (13.3.1) into submission and at that point, the target settings "Frameworks, Libraries and Embeddable" section was actually able to display the swift package's "Foo" binary. Added it, and then everything was playing nice.
So, if you're still having problems, try simplifying the problem by opening smaller morsles if you can. Or start making these wrapper frameworks (if it's at all possible) so that you can actually manage smaller bites before integrating them on XC's platter.
For me, I go to Xcode -> File (The one on mac top bar) -> Packages -> Update to Latest Package Versions. This solved my problem.
In order to keep incremental builds working I had to specify the output files of "Fix SPM" build phase like so:
I am trying to install package Payum/PayumBundle,I add
"require-dev": {
"payum/payum-bundle": "1.0.0-BETA2"
}
to indicate I also need to download dev version.
this gives me an error:
Problem 1
- The requested package payum/payumbundle could not be found in any version, there may be a typo in the package name.
Potential causes:
- A typo in the package name
- The package is not available in a stable-enough version according to your minimum-stability setting
see <https://groups.google.com/d/topic/composer-dev/_g3ASeIFlrc/discussion> for more details.
how do we find the right version constraint from git tag ,branches?
what I tried :
2. tried the version constraint following
1.0.*#beta , 1.0.0 , 1.0.*#beta ,1.0.*#dev,1.0.0#beta
the result is still the same
the latest tag for this project is
1.0.0-BETA2
what is the correct version constraint for this? this post explains what a version constraint can be , but it doesn't explain how to find the right version constraint from git tag.
The easier way how to get proper version name, is go to package detail on packagist.org.
There you'll find out there are no BETA tags available. It might be caused by not triggering autoupdate by Github.
You can see, the last dev version is: 1.0.x-dev
So this command would normally do the trick:
composer require payum/payum-bundle:1.0.x-dev
But this package depends on another dev package, so you need to mention them both in your composer.json. Like this:
{
"require": {
"payum/payum-bundle": "1.0.x-dev",
"payum/core": "1.0.x-dev"
}
}
And run:
composer update
That's all :). Verified!
We're running eXist-db version 3.0 and want to try running XProc within it.
We found that the XProcxq Module is now part of eXist: http://exist-db.org/exist/apps/doc/extensions.xml#module_xprocxq
However, in attempting to use it we get the error below and wondered if anyone had suggestions for where we could be going wrong?
As specified at the top of the module page linked to, we added the module to the conf.xml file and restarted eXist. (This could be where we went wrong, but that's a guess on our part)
This is what the module we added looks like in conf.xml:
<module uri="http://xproc.net/xproc" class="org.exist.xquery.modules.xprocxq.XProcxq/>
Here is the simple started XQuery I've attempted to use:
xquery version "1.0" encoding "UTF-8";
import module namespace const = "http://xproc.net/xproc/const";
import module namespace xproc = "http://xproc.net/xproc";
import module namespace u = "http://xproc.net/xproc/util";
declare variable $local:XPROCXQ_EXAMPLES := "/db/examples"; (:CHANGE ME:)
let $stdin :=document{<test>Hello World</test>}
let $pipeline :=document{
<p:pipeline name="pipeline"
xmlns:p="http://www.w3.org/ns/xproc"
xmlns:c="http://www.w3.org/ns/xproc-step">
<p:identity/>
</p:pipeline>
}
return
xproc:run($pipeline,$stdin)
Here is the error:
error found while loading module xproc: IO exception while loading module 'http://xproc.net/xproc' from 'http://xproc.net/xproc'
I posed your question to the exist-open mailing list (where I'd encourage you to join for future eXist-db questions), and it appears XProc support in eXist is currently between a rock and a hard place. The xprocxq library you mentioned is woefully underdeveloped (abandoned by its original creator), and the much better developed Calabash module is incompatible with the current version of Saxon used in eXist, due to a dependency on that version of Saxon. I'd welcome you to join exist-open to discuss further. Perhaps there's some other workaround for you.
It needs to be rebuilt.
According to http://exist-db.org/exist/apps/wiki/blogs/eXist/eXist30RC1
EXPath packages that incorporate Java libraries may no longer work with eXist 3.0 and may need to be recompiled for our API changes; packages should now explicitly specify the eXist versions that they are compatible with.
I am working on the update to the XProc EXPath module.
The XMLCalabash module for eXist has now been rebuilt for a newer version of eXist and Calabash and should work with eXist 3.0.RC1.
To build your own Jar package for eXist 3.0.RC1 run:
$ git clone https://github.com/eXist-db/eXist-XMLCalabash.git
$ cd eXist-XMLCalabash
$ rm -rf src/test
$ mvn package
The Jar is then in the target/ folder. You should copy it to $EXIST_HOME/lib/user modify $EXIST_HOME/conf.xml to load the module and then restart eXist.
Updated
The XML Calabash module for eXist, now also has a PR so that it will support the upcoming eXist 3.0.RC2 -
https://github.com/eXist-db/eXist-XMLCalabash/pull/2
However you cannot built it remotely until eXist 3.0.RC2 is released.