Comments (9)
Hello Martin, and thanks for your question!
Unfortunately, you’re right: there’s no way to automatically include the SPM list of dependencies for a given project with AcknowList. Right now, you need to either hard-code the list (as an array of Acknow
instances), or create a plist similar to what CocoaPods is generating, and use the auto import.
But that would be my top-priority feature request for AcknowList. The problem is that I’m not sure how to do it.
To my knowledge, the best solution to find the list of resolved dependencies is to look at [appName].xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved
, as hinted on https://developer.apple.com/documentation/swift_packages/building_swift_packages_or_apps_that_use_them_in_continuous_integration_workflows (it doesn’t include local packages, though). So maybe we’d have to import that file into the main target, like we do for the CocoaPods plist? That gives us the list of packages with names and URLs, but not the licenses. Should we try to somehow fetch the licenses from each repo? When compiling, or when running? Or just open the repo instead of the license?
I know, lots of questions, but again, I think that’s the next step for AcknowList, as SPM seems to slowly overtake CocoaPods.
from acknowlist.
Alright, I’ve opened a pull request with the new SPM support (with Package.resolved
files): #102.
There’s also a good amount of refactoring, especially around AcknowParser
to manage the fact that we support multiple file types. Please give it a try, and let me know what you think. 🙌
from acknowlist.
Hey @vtourraine,
I just gave it a first try and it works great so far.
However, I am facing a crash on my private Swift packages, see https://github.com/vtourraine/AcknowList/pull/102/files#r893423676 pls.
For me, it is easy to work around this by simply filtering my private packages, which I am about to do anyways. However, you may wanna add some kind of a URL validation to prevent client apps from crashing?
Cheers,
Martin
from acknowlist.
Hello Martin, and thank you for your message. You’re right, the PR should be ready. I just didn’t have the time recently to check everything (documentation, breaking API changes, etc). I’ve blocked some time for next week, it should be merged then. Cheers 🙌
from acknowlist.
Update: it’s now merged into main
🎉
As previously discussed, this will be a “version 3” update, given the amount of interface changes. I’m thinking of releasing it alongside Xcode 14 in September. Probably not much that will change because of iOS 16/Swift 5.7 per se, but that’s always a nice time to move things forward.
from acknowlist.
Hi @vtourraine,
thanks for sharing your thoughts on this.
I understand now, it's tricky. I guess there is even no one-single-way of providing a license text as a Swift Package. However, having / including a list of packages is a good staring point & better than nothing, I would say.
Generally speaking, I am a big fan of simply baking such kind of stuff into the app. So gathering everything at build time. However, fetching various license texts on every build sounds horrible. Taking into consideration that this process may even attempt different patterns such as $repoBaseUrl/blob/master/LICENSE
vs. $repoBaseUrl/blob/master/LICENSE.txt
vs … and so on, only makes it worth. So if done at build-time some sort of caching would be needed. With that, we are almost at the plist file approach. For a plist file, some script could help to build it, but this would still be clunky as dev would have to take care of running at appropriate times.
Here is another idea:
- Gather the list of Swift packages from the
Package.resolved
file and include them in the list ofAcknowListViewController
. - Then have a dedicated details screen for SwiftPM packages, which would display the data points we get from
Package.resolved
. This details screen could link to the GitHub project of package being displayed. One could take it from there. - To take this one step further, this details screen's
ViewController
could attempt to fetch theLICENSE[.txt]
(whatsoever) from the packages repo. If none of the fetching works, it may just fail gracefully. I would include some sort of loading state while the license text is search for.
Regards, Martin
from acknowlist.
Alright, let’s do this 🚀
I’ve added a new branch: https://github.com/vtourraine/AcknowList/tree/parse-packages
Right now, it only parses the titles and repository URLs from Package.resolved
files (I’ve actually found 2 different formats for those files). I’ll try to implement the rest later. It does change the model a little bit, so in theory this should be released as a major new version. I’ll try to find a nice programming interface to make it as easy-to-use and discoverable as possible, despite the added complexity of supporting multiple file types.
from acknowlist.
🤩 Awesome!
Lemme know if there is anything I can help you with.
from acknowlist.
Hey @vtourraine how are things going on your side?
I think PR #102 is done now, thus can get merged and eventually released.
Bests, Martin
from acknowlist.
Related Issues (20)
- AcknowList 2.1.1 not working in a pure SPM project HOT 3
- Dependency licenses are not displaying HOT 1
- Exclude a pod HOT 2
- Not able to see License Page in Swift 5 HOT 3
- Change Navigation Title in SwiftUI HOT 2
- Question: Does the library supports Settings bundle based display for licenses/acknowledgements for used libraries ? HOT 7
- Problem with transparent list and rows HOT 3
- Licencia free
- Unable to make it work with SwiftUI on macOS HOT 4
- Cocoapods version & readme not up to date HOT 4
- Ability to run as a script, without adding to the target HOT 10
- [Feature]: Add Privacy Manifest HOT 2
- defaultPackages not returning the list HOT 1
- Return the library details in csv HOT 1
- Change VC title "Acknowledgements" HOT 1
- Plist via SPM HOT 1
- SwiftUI Views not included in latest Release HOT 1
- SwiftPM usage has docc included in build files HOT 1
- 'NSInternalInconsistencyException' on iOS 15.2 HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from acknowlist.