I have a Swift package in a subdirectory of a git repository inside GitHub. The tree looks something like this:
.
├── swift-package
│ ├── Package.swift
│ └── Sources
│ └── SomeLibrary
│ └── Library.swift
└── some-other-files
I want to add swift-package as a dependency to another project.
But the only way of specifying a dependency using Swift Package Manager I know is when the package is at the top level of the repository:
dependencies: [
.package(url: "http://github.com/Some/Repository", from: "1.2.3"),
],
What I would need would be something along the lines of .package(url: "http://github.com/Some/Repository, dir: "swift-package"...).
I have no way of moving out the package to a separate repository.
Is there any way to achieve something like this using Swift Package Manager? If not, what are my options? Also, what is the best way to submit a feature request to Swift Package Manger developers?
You can not have two Swift packages in the same git repository. The Swift Package manager defines a package as:
Packages are Git repositories, tagged with semantic versions, containing a Package.swift file at their root. Initializing the
package created a Package.swift file, but to make it a usable package
we need to initialize a Git repository with at least one version tag.
Your options are to either have separate repositories/packages for your dependencies, or use one repository and move the code in separate modules/targets.
If you need to submit a feature I would first start a discussion in the Swift forums describing your goals and requesting feedback from the community. The code for the Swift PM is hosted in github you can always submit a pull request with a new feature. More information about the process is described here.
Not exactly the proper answer, but I wonder if, as a workaround, we could add the corresponding repo as Git submodule, and then integrate the package as a local package from the corresponding subdirectory. We would lose the ability to update (or change the version of) the package via SPM, though. On the other hand, we would still be able to control the version of the package, by pinning the Git submodule to version tags (or branches/commits/whatever), that should be there in Git repository anyway for SPM, if I recall it correctly.
Related
I'm writing a Swift Package that relies on another package that I manage (Netswift). I've setup a bleeding_edge branch there, where I commit every few hours (i.e when I notice access control is wrong, or any other minor edit).
Now my current package has a dependency on the github repo for Netswift, with that bleeding_edge branch, as pictured below:
dependencies: [
.package(url: "https://github.com/MrSkwiggs/Netswift", .branch("bleeding_edge")),
]
Unfortunately, resolving the dependency graph by any of the following means (updating Package.swift with an empty space somewhere, running swift package update) does not pull new commits from that branch.
The only way I found to force-update is to specify a different branch, resolve dependency graph, then revert back to the branch I actually need, then resolve dependency graph again.
Is there a better way to force-update the dependency graph?
I also don't want to add a target with an absolute path to this other local package, as colleagues will also need to rely on this at some point in the future.
You need to use XCode's built-in package update functionality, which can be found under:
File -> Swift Packages -> Update to Latest Package Versions
Running swift package update only works when the package is being worked on as a standalone; if the package is being edited through an existing XCode project/workspace then you need to let XCode handle it.
Normally, we get our Nuget.config from users\[loggedinuser\AppData\Roaming\Nuget but we have a case where a specific project where we need a use a different project specific config file. Where do I place the config file in this case?
I am using .net core SDK 1.0.4 and .net code.
The build script does this:
cd src\SFMC.Adapter.Service
dotnet restore
dotnet build
Can I pass an argument into dotnet restore to indicate the location of the config?
Assuming your project structure looks like:
Project/
└── src
├── SFMC.Adapter.Client
├── SFMC.Adapter.Service
│ ├── Program.cs
│ └── Project.csproj
└── SFMC.Adapter.Service.Test
You can add a Nuget file anywhere within the project tree. Where you place it will affect which projects see it by default. dotnet restore will search for all Nuget.config files up the directory tree to add any sources it finds.
If you place it next to Service.cs, it will only be picked up by SFMC.Adapter.Service. If you place it under src it will be picked up and used by SFMC.Adapter.Service, SFMC.Adapater.Service.Test and SFMC.Adapter.Client.
See NuGet configuration docs for more details.
I know it is a rather old post, but I was struggling with it as well and had a hard time finding the correct documentation. I eventually found that you can execute the command below to add a new nuget config to the location where you are.
dotnet new nugetconfig
This will use the dotnet cli to use the nugetconfig template (that appeared to be installed by default) to generate a correct file
From the Nuget docs:
Project-specific NuGet.Config files located in any folder from the solution folder up to the drive root. These allow control over settings as they apply to a project or a group of projects.
So you can put a Nuget config file alongside the project file to give that project a specific configuration.
I've two Swift PM projects, both use some common code which I would like to store perhaps in a separate project, say a library, which then these two would be able to import.
I've used swift init --type library and so on to build a library but is there any other documented way of including it in the other projects without having to submit it to github and providing the link to the repo to the swift package manager?
I'm thinking something around the lines of building the library project and having a script which copy pastes it wherever it needs to be to be accessible to the other projects (in their own directories if need be)
According to the Swift Package Manager Usage documentation a swift package is designed to be used as a git repository.
Simply put: a [Swift] package is a git repository with semantically versioned tags, that contains Swift sources and a Package.swift manifest file at its root.
That said, the dependencies documentation section states that the depedency path can be a local path.
[Dependencies] is the list of packages that the package depends on. You can specify a URL (or local path) to any valid Swift package.
Note that the git tags are useful (needed) to manage which version of a dependent package is included.
// 1.5.8 ..< 2.0.0
.package(url: "path/SharedPackage", .upToNextMajor(from: "1.5.8")),
// Constraint to an arbitrary closed range.
.package(url: "path/SharedPackage", "1.2.3"..."1.2.8"),
// Branch and revision.
.package(url: "path/SharedPackage", .branch("develop")),
Key Points:
Treating the local package as the same local git repository could still align one's workflow with the Swift Package Manager design.
Some remote or additional git repository is not required because local dependency paths of the Swift package(s) can be used.
Basically, using git in a more simplified and streamlined way may be worth considering for the local-only, some-shared-code use case.
I'm testing the current buildroot 2016.02-rc2 release. It contains gstreamer1 packages for version 1.6.3, but I would like to build 1.7.2 instead. I successfully updated package definitions for gstreamer1 and the most important plugins to use 1.7.2. However gst-omx has only a 19 months old release archive for the version 1.2.0 for the direct download (https://gstreamer.freedesktop.org/src/gst-omx/) and it fails to compile. So I would like to use the latest version from git repo.
How can I do it? git repository contains a "common" submodule which buildroot's build system cannot handle as it seems. I thought about creating a new release tar.xz package, that would contain everything for building it like all other gstreamer packages, but couldn't find out how those tar.xz packages on the server are generated...
There is indeed no support for submodule in Buildroot, since most of the time, submodules should be packaged as separate packages.
So, for your own testing, you have two options:
1/ You can do a quick test by creating yourself a tarball that contains all the gst-omx source code (including the contents of the common/) subdirectory.
2/ You can package the gstreamer common stuff as a separate package, make your gst-omx package depend on it, and in a pre-configure hook, create a symlink $(#D)/common -> $(GSTREAMER_COMMON_DIR)
A while back I had to use a jQuery plugin in my project. I needed some different functionality,
so I rewrote the plugin and a few days back I published a fork on github. I wanted to add the
package to the bower repository.
The forked repository
I added a bower.json file to the repository and registered the package with the usual "bower register" command.
The problem is, when I try to install my package, bower installs the original script and not the fork.
What I already tried:
At first I thought it's because I didn't make a release, so I fixed that part. But It didn't help.
I also tried to change the version number to the version number of the original script with no luck.
So maybe the bower.json file I wrote was not well written, right? My next attempt was using Bower to
make a propper bower.json file for me using "bower init". No luck.
So what could I be doing wrong?
The GitHub help page defines a fork as a method to use someone else's project as a starting point for your own idea.
That was my intention since I rewrote the plugin to be oo oriented and added some functionality, but 80% of the code
used is still from the original plugin and it didn't feel right to just make a new repository. Should I instead make a new repository
and will registering my repo with Bower work then?
What is the usual approach if you did some medium to major changes to a repository? Do you fork it or publish a new repo?
Do you still make a pull request even if the changes are bigger?
This worked for me :
Fork the repository
Clone on your disk
Increment the version number in bower.json (ex. 2.0.1)
Commit and push
Create a new version tag higher than the forked repository. ex: git tag "2.0.1"
Push : git push --tag
bower install "https://github.com/myname/forkedrepo.git#2.0.1"
You don't need to create a new repository. A fork will work fine.
But you can't overload on someone else's registered package name with bower. It does look like you've changed the name from onepage-scroll to onepage-scroll-extended though.
If you want to figure out what Bower knows about your package:
Do: bower info onepage-scroll-extended
{
name: 'onepage-scroll-extended',
homepage: 'https://github.com/itd24/onepage-scroll-extended',
version: '1.1.1'
}
Available versions:
- 1.1.1
- 1.0.1
Here you can see that it does not have the full bower.json manifest information and the latest information that it has is for version 1.1.1 (not 1.1.3, your latest).
This is because you don't have a v1.1.3 tag in your repository's master branch. I can see a v1.1.1 and v1.2 tag, but no v1.1.3 tag. Create that tag and push it up to GitHub to enable you to bower install that new version.
You may also need to re-run the bower register command to tell it to pick up the latest manifest. This should be happening automatically (AFAIK). You don't include the bower register command that you ran, perhaps you used the wrong repo URL there. You should use something like:
bower register onepage-scroll-extended git#github.com:itd24/onepage-scroll-extended.git