cocoapods / core Goto Github PK
View Code? Open in Web Editor NEWThe models used within the CocoaPods gem
License: MIT License
The models used within the CocoaPods gem
License: MIT License
The objects should be configured using the API offered for programmatic access.
With the latest version of CocoaPods, the resources script is failing. I believe I've tracked it down to b32cae7888e1feb9432da177b65193ce8547331f, which removed the quotes around the second part of the xcrun
command.
Was this a mistake, or were they removed for a reason?
The check should be implemented here: https://github.com/CocoaPods/Core/blob/master/lib/cocoapods-core/specification/linter.rb#L209-L211.
This issue was first found at the CocoaPods level and reported in issue CocoaPods/CocoaPods#1489
Relevant discussion from that issue:
@jominius:
Original Title: CocoaPods versioning “< 2.0” tried to install “2.0.0-RC3”
I have a project, which was using some unknown old version of AFNetworking. I converted the project to CocoaPods and wrote "pod 'AFNetworking', '< 2.0'" into pod file.
Found out that "pod install" tried to install AFNetworking version 2.0.0-RC3. Fortunately it wasn't compatible with the project and I got a warning about it.
Yes, we should not install rereleases unless explicitly requested by the user. E.g. pod 'AFNetworking', '2.0.0-RC3'.
I submitted a pull request with several tests, one of which is failing and reproduces the issue that @jomnius reported.
After further investigation, this looks like it will have to be fixed in Core, probably in dependency. I think it would still be good to have these tests at the CocoaPods level, though.
Pod::DSLError - Invalid `ARAnalytics.podspec` file: undefined method `author=' for #<Pod::Specification name="ARAnalytics">
I had to make this commit: orta/ARAnalytics@5a935dc in order to not have cocoapod 0.17 rc5 give install issues
I've created a pod that depends on the Parse pod. My podspec includes the line
s.dependency "Parse"
When I create a new project and try to use my pod (https://raw.github.com/pyro2927/ParseQuickDialog/master/ParseQuickDialog.podspec) and build, I get an error that Pods-ParseQuickDialog
has an issue where Parse/Parse.h
cannot be found. I'm guessing this is due to the fact that the Parse iOS SDK is distributed via a framework and not source code, but I'm unsure as to how to fix the problem.
My guess is the Parse framework isn't being included in the build process for my pod (ParseQuickDialog), but I don't know where that needs to be fixed.
I've found a very subtle yet potentially serious issue where the version of a dependency is miscalculated or multiple copies of the dependency are installed.
Note that I assume this is an issue in Core based on my guess of how the various CocoaPods repos depend on each other. Let me know if this issue is mis-filed and I will happily recreate in the correct repo.
This issue originally arose when my app's Podfile depended on a loose (~> 2.0) version of an AFNetworking subspec. Two pods called out in the Podfile also depended on loose versions of AFNetworking subspecs. When I ran pod install
on 2/26 (when 2.2 was released), I ended up with both 2.1.0 and 2.2.0 versions of AFNetworking installed on top of each other, causing compiler issues.
I've since determined that whether the Podfile specifies a dependency on the subspec or the top-level spec does not matter. The version of the dependency in the Podfile also doesn't matter much since even pinning it to a specific version (= 2.1.0) causes the issues. What matters is the (shared) dependency declaration in the referenced podspec.
shared dependency == AFNetworking
I've created a project which reproduces these issues at https://github.com/phatblat/SubspecUpdateIssue. Toggle the AFNetworking dependency lines in ZPodUsingAFN.podspec between the subspec and the top-level spec and run pod install
to witness the above 2 issue cases.
If someone gives me some pointers on the pertinent details I might be able to include them in an example at https://github.com/CocoaPods/cocoapods-integration-specs/.
Reproducing the case where pod install
upgrades a pod it shouldn't have with a fuzzy version spec (~> 2.0) is harder to reproduce as it requires a Podfile.lock created while the offending version didn't exist. However, I believe the above cases are enough to resolve the current issue since it's reproducible with a pinned version in the Podfile.
Originally reported in #44 (comment)
Often when users rename there github accounts there is a linter failure when they add a new spec. It fails saying something like:
- ERROR | The source of the spec doesn't match with the recorded ones. Source: `https://github.com/supermarin/ObjectiveRecord.git`. Previous: `https://github.com/mneorr/Objective-Record.git`
Please contact the specs repo maintainers if thelibrary changed location.
-> The spec cannot be accepted.
It would be great if the linter could follow the redirections to see that the URL is actually the same in both cases.
Currently when using vendored_frameworks
you also have to specify source_files
or public_header_files
, which is slightly redundant.
See CocoaPods/#1836
The DSL should be isolated as much as possible from the Specification class which should be concerned only in handling the attributes hash and provide ancillary support. The specification should still be based on the attributes.
Moreover the specification consumer and its division of root attributes is counter intuitive and this should be fixed.
I'm sure everyone can pipe in, but with the number of linter improvements I've made I'd like to see if we can make a bit more of a concrete list of areas that we should be checking for inside of it. This will also help keep things a bit more organized/documented on what we need to work on in this area.
As PodSpecs can by loaded by JSON or YAML files it would be useful to highlight any non supported key.
This should be implemented in a dedicated method in https://github.com/CocoaPods/Core/blob/master/lib/cocoapods-core/specification/linter/analyzer.rb#L6. The implementation could check the Pod::Specification#attributes_hash
against the Pod::Specification::DSL.attributes
. Each attribute agains the Pod::Specification::DSL::Attribute#name
which is used as a key for the hash storing them
This should be a module in Core to avoid code duplication between Core and CocoaPods itself. It will support validating URLs despite of redirects and some common errors we identified so far.
As I touched that code a lot recently, I will do it myself.
Support for fuzzy search has been already implemented in the Source
class, although the cocoapods
gem is not taking advantage of it yet. Currently the implementation is backed by the fuzzy_match
gem which however appears to be geared to a slightly different use case that the one we are looking after.
One major limitation is that it doesn't take into account case to tokenize the names of the Pods. For example I consider convenient ObjSug
to indicate ObjectiveSugar
. This is very convenient for commands like pod spec cat
and for printing a suggestion to the user including a similarly named Pod if one dependency in the Podfile could not be resolved.
lib/cocoapods-core/specification/dsl.rb
lists the documentation
attribute as an available option, but this attribute was deprecated in 0.20.0. Because dsl.rb
is used to generate Cocoapods' documentation, this causes the Specification documentation to incorrectly list the documentation
attribute as still being available.
A spec should not be considered empty if it has a framework in vendored_frameworks
even if that is the only attribute where it includes source files. check_if_spec_is_empty
should also check for vendored_frameworks
in this array
@alloy said we should remove mentions of ‘spermy’
This will effectively mirror the RubyGems pull request: rubygems/rubygems#124
This could be useful if a pod isn't as simple as install and #import
originally reported by @alloy in #44
Disallow the use of the vendored_frameworks for iOS specs. These are not frameworks, but instead are static libraries disguised as frameworks and this makes it harder to use these specs outside of the context of Xcode. E.g. with clang from the command-line. Ideally this would also check the xcconfig attribute to ensure it’s not adding any FRAMEWORKS_SEARCH_PATHS.
This is a migration of the issue tracked on CocoaPods/CocoaPods#583 and the associated Pull Request CocoaPods/CocoaPods#584 into the Core module.
I just pushed a version of the RestKit Podspec with the version 0.20-dev. On testing the installation, version.rb blew up at me complaining that the version string is malformed. I checked the Podspec format document @ https://github.com/CocoaPods/CocoaPods/wiki/The-podspec-format, which says that the version attribute reference should consult Semver.
Looking at the Semantic Version docs @ http://semver.org/ it says this about pre-release versions:
A pre-release version MAY be denoted by appending a dash and a series of dot separated identifiers immediately following the patch version. Identifiers MUST be comprised of only ASCII alphanumerics and dash [0-9A-Za-z-]. Pre-release versions satisfy but have a lower precedence than the associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
The version enforcement should be updated to match the specification. Pull request forthcoming...
The system under test should be referenced by the sut
acronym instead of using different names. This convention is concise and simplifies refactors.
For example @set
should be changed to @sut
in this line
edit by @fabiopelosin
I'm sure this has come up in conversation has come up before. It would be nice to have an attribute on a spec like deprecated
as a boolean that would alert users when they were installing a deprecated pod. CocoaPods/Specs#8326 The only way people seem to be alerting users of deprecations now is by adding a small line to the summary.
If this was thought of as being too talkative there could be a ignore_deprecations
field that could be added to a user's Podfile.
The linter throws a warning when comments need to be removed from this line based on /^\s*#/
The issue with this is podspecs like freexl that injects a ton of #define
statements. These are treated as comments and therefore not accepted.
-> freexl (1.0.0d)
- WARN | Comments must be deleted.
One workaround for this might be to change the regex to /^\s*#\s+/
to only recognize comments when there is at least one space between the #
and the text after it. Obviously people could submit actual comments using that method as well (which we wouldn't like) but that would fix most cases where the issue is they didn't remove the initial comments after creating a blank spec.
What do you think?
Just updated ruby to 2.0.0 and cocoapods to 0.21
when I'm trying to lint:
pod repo lint master
i have :
-> The specification defined in `/Users/flop/.cocoapods/master/cocos2d/2.0/cocos2d.podspec` could not be loaded.
Invalid `cocos2d.podspec` file: uninitialized constant Pod::FileList
#
# from /Users/flop/.cocoapods/master/cocos2d/2.0/cocos2d.podspec:14
And same issue in some other podspecs
It can be fixed just by adding
require 'rake'
FileList = Rake::FileList
in podspec file
Currently, we just catch all exceptions there
Core/lib/cocoapods-core/http.rb
Line 44 in b20ca02
We should evaluate which specific error conditions we want to ignore. Invalid URIs should be checked before even making the request and get their own specific error messages.
A proper informative message should be provided in the following cases:
A good starting point is the Pod::Source::FileSystemDataProvider#versions method.
Currently the sub keys of the hashes use symbols (e.g. source
the source params like :git
). There is already logic there to handle the conversion when appropriate... but all the keys should be used as strings and converted, if needed, by the consumer.
This would also lead to a cleaner Lockfile:
EXTERNAL SOURCES:
IFBKCampground:
:git: https://github.com/irrationalfab/IFBKCampground.git
IFBKThirtySeven:
:path: ../../IFBKThirtySeven
IRFAutoCompletionKit:
:git: https://github.com/irrationalfab/IRFAutoCompletionKit
IRFNavigationKit:
:git: https://github.com/irrationalfab/IRFNavigationKit.git)
Related: CocoaPods/CocoaPods#1058 (comment)
@alloy we need to double check this for trunk because the JSON podspec return strings.
Ensure the libraries and vendored_libraries attribute contains e.g. ‘foo’ and not ‘libFoo.a’.
Ensure the vendored_frameworks attribute contains e.g. ‘Foo’ and not ‘Foo.framework’.
Frameworks should be allowed to have more than just letters and numbers. As it currently stands those are the only characters allowed although some frameworks have -
in the name. This can be fixed by changing the regex to /[^a-zA-Z\-\d]/
and writing a test or two.
I’m just gonna list issues here as I come across them.
:local
option, that isn't expanded (e.g. contains a tilde) or can’t be found results in an exceptionNo such file or directory - ~/Code/Fingertips/github/FTWebViewController
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/generator/documentation.rb:63:in `chdir'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/generator/documentation.rb:63:in `generate'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/installer/pod_source_installer.rb:134:in `block in generate_docs'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/user_interface.rb:43:in `section'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/installer/pod_source_installer.rb:133:in `generate_docs'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/installer/pod_source_installer.rb:84:in `install!'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/installer.rb:312:in `install_source_of_pod'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/installer.rb:282:in `block (2 levels) in install_pod_sources'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/user_interface.rb:43:in `section'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/installer.rb:281:in `block in install_pod_sources'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/installer.rb:279:in `each'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/installer.rb:279:in `install_pod_sources'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/installer.rb:91:in `block in install!'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/user_interface.rb:43:in `section'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/installer.rb:89:in `install!'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/command/project.rb:40:in `run_install_with_update'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/command/project.rb:70:in `run'
/Users/eloy/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/claide-0.2.0/lib/claide.rb:535:in `run'
/Users/eloy/code/CocoaPods/CocoaPods/lib/cocoapods/command.rb:36:in `run'
/Users/eloy/code/CocoaPods/CocoaPods/bin/pod:16:in `<main>'
Finding Podfile changes:
Resolving dependencies of `Podfile`
Resolving dependencies for target `default' (iOS 6.0)
Comparing resolved specification to the sandbox manifest:
Downloading dependencies
Using CocoaLumberjack (1.6)
Using DirectoryWatchdog (1.0.0)
Using FTWebViewController (0.0.1)
Using HockeySDK (2.5.5)
Using SYPaginator (0.0.1)
Using StyledPageControl (1.0)
Generating Pods Project
Integrating client projects
At the very least, the first 4 lines could be condensed to something short like ‘Resolving dependencies’.
The deletions are also too verbose:
Removing deleted dependencies
Removing StyledPageControl
I’m leaning towards just showing the first line only, but I’m not sure yet.
Another option, which is more like how it currently works, is to make ‘Installing X’ lines green and ‘Deleting X’ lines red (in which case only the second line of the above example should be used).
Take for instance the SYPaginator lib, which specifies the following resources pattern: Resources/*
. Previously this lead to the following lines in the resources script:
install_resource 'SYPaginator/Resources/de.lproj'
install_resource 'SYPaginator/Resources/en.lproj'
install_resource 'SYPaginator/Resources/es.lproj'
install_resource 'SYPaginator/Resources/fr.lproj'
install_resource 'SYPaginator/Resources/id.lproj'
install_resource 'SYPaginator/Resources/it.lproj'
install_resource 'SYPaginator/Resources/ja.lproj'
install_resource 'SYPaginator/Resources/ko.lproj'
install_resource 'SYPaginator/Resources/ms.lproj'
install_resource 'SYPaginator/Resources/nl.lproj'
install_resource 'SYPaginator/Resources/pt.lproj'
install_resource 'SYPaginator/Resources/pt_PT.lproj'
install_resource 'SYPaginator/Resources/ru.lproj'
install_resource 'SYPaginator/Resources/sv.lproj'
install_resource 'SYPaginator/Resources/SYPaginatorResources-Info.plist'
install_resource 'SYPaginator/Resources/zh_Hans.lproj'
install_resource 'SYPaginator/Resources/zh_Hant.lproj'
But currently only adds:
install_resource 'SYPaginator/Resources/SYPaginatorResources-Info.plist'
So it’s clear that all the directories are being ignored and it only includes files.
I have a workspace that was previously generated by CocoaPods 0.16. Later on I added a third unrelated Xcode project to the workspace. This has always been fine, because CP would change the workspace anymore.
Now it regenerates the workspace but does not include the third unrelated project.
Before:
<?xml version='1.0' encoding='UTF-8'?>
<Workspace version='1.0'>
<FileRef location='group:Report 2012.xcodeproj'/>
<FileRef location='group:Vendor/PSPDFKit-2.8.2/PSPDFKit/PSPDFKit-lib.xcodeproj'/>
<FileRef location='group:Pods/Pods.xcodeproj'/>
</Workspace>
After:
<?xml version='1.0' encoding='UTF-8'?>
<Workspace version='1.0'>
<FileRef location='group:Report 2012.xcodeproj'/>
<FileRef location='group:Pods/Pods.xcodeproj'/>
</Workspace>
This is already done for the license and for the description.
It should be done also for the:
This class doesn't belong in Core and for that matter to the command line tool in my opinion. It should be handled by https://github.com/CocoaPods/metrics.cocoapods.org.
Also I'm of the opinion that pod search --stats
should be remove in favour of the search provided by cocoapods.org.
Marked as blocked because it requires trunk to be operational.
We had an issue pop up in the specs repo CocoaPods/Specs#10877 where a contributor submitted a spec using git@github...
However, specs should be using https
. I notice the local linter passes this fine, which I can understand for private repos, but I wonder if this behaviour should not pass if contributing to the master repo?
There's quite a discussion in that pull request so I thought it might be more appropriate to raise an issue here instead.
Looks like #77 was a bad idea.
[10] pry(main)> URI.parse('[email protected]:foo/dfs.git')
URI::InvalidURIError: bad URI(is not URI?): [email protected]:foo/dfs.git
from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/uri/common.rb:176:in `split'
[11] pry(main)> URI.parse('/Volumes/myrepo/source code')
URI::InvalidURIError: bad URI(is not URI?): /Volumes/myrepo/source code
from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/uri/common.rb:176:in `split'
I think this error is providing some false positives. I'm getting this for the Baidu-Analytics-SDK
where the homepage URL is: http://mtj.baidu.com/ which redirects to http://mtj.baidu.com/web/welcome/login
I'm not sure if this is just a redirection issue or if that's intentional since it doesn't return a 200.
Ruby uses a magic comment in the first line of the file to specify the encoding of the file. Otherwise ASCII is assumed.
To specify utf8, a comment like this is put into the first line of the source file:
# -*- coding: utf-8 -*-
When running pod lib lint
on this, a warning is issued and the lint fails. This is the output:
$ pod lib lint
-> Pixltag (0.1.0)
- WARN | Comments placed at the top of the specification must be deleted.
[!] Pixltag did not pass validation.
You can use the `--no-clean` option to inspect any issue.
I don't think this is very helpful. Non-ascii names are impossible to use then.
As seen in https://github.com/Marxon13/Specs/commit/8ca38c40a2c8db87ce97b944417425623d18a737
A simple regex rule for detecting invalid names, such as with ,
and spaces etc.
from
Pod::Spec.new do |spec|
def spec.pre_install(pod, target_definition)
Dir.chdir(pod.root){ `sh make.sh` }
end
end
to
Pod::Spec.new do |spec|
spec.pre_install do |pod, target_definition|
Dir.chdir(pod.root){ `sh make.sh` }
end
end
/cc @alloy
You get a non-trivial to figure error report:
Psych::SyntaxError - (<unknown>): could not find expected ':' while scanning a simple key at line 14 column 1
/Users/orta/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/psych.rb:205:in `parse'
/Users/orta/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/psych.rb:205:in `parse_stream'
/Users/orta/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/psych.rb:153:in `parse'
/Users/orta/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/psych.rb:129:in `load'
/Users/orta/.rvm/gems/ruby-2.0.0-p247/gems/cocoapods-core-0.29.0/lib/cocoapods-core/lockfile.rb:43:in `from_file'
/Users/orta/.rvm/gems/ruby-2.0.0-p247/gems/cocoapods-0.29.0/lib/cocoapods/config.rb:208:in `lockfile'
/Users/orta/.rvm/gems/ruby-2.0.0-p247/gems/cocoapods-0.29.0/lib/cocoapods/command/project.rb:36:in `run_install_with_update'
/Users/orta/.rvm/gems/ruby-2.0.0-p247/gems/cocoapods-0.29.0/lib/cocoapods/command/project.rb:68:in `run'
/Users/orta/.rvm/gems/ruby-2.0.0-p247/gems/claide-0.4.0/lib/claide/command.rb:213:in `run'
/Users/orta/.rvm/gems/ruby-2.0.0-p247/gems/cocoapods-0.29.0/lib/cocoapods/command.rb:51:in `run'
/Users/orta/.rvm/gems/ruby-2.0.0-p247/gems/cocoapods-0.29.0/bin/pod:24:in `<top (required)>'
/Users/orta/.rvm/gems/ruby-2.0.0-p247/bin/pod:23:in `load'
/Users/orta/.rvm/gems/ruby-2.0.0-p247/bin/pod:23:in `<main>'
/Users/orta/.rvm/gems/ruby-2.0.0-p247/bin/ruby_noexec_wrapper:14:in `eval'
/Users/orta/.rvm/gems/ruby-2.0.0-p247/bin/ruby_noexec_wrapper:14:in `<main>'
From:
PODS:
- Kiwi (2.2)
- ObjectiveSugar (1.1.1)
DEPENDENCIES:
- Kiwi
- ObjectiveSugar (from `../`)
EXTERNAL SOURCES:
ObjectiveSugar:
:path: ../
SPEC CHECKSUMS:
<<<<<<< HEAD
Kiwi: 05f988748c5136c6daed8dab3563eca929399a72
ObjectiveSugar: 7377622e35ec89ce893b05dd0af4bede211b01a4
=======
Kiwi: db174bba4ee8068b15d7122f1b22fb64b7c1d378
ObjectiveSugar: 27c680bb74f0b0415e9e743d5d61d77bc3292d3f
>>>>>>> b65623cbf5e105acbc3e2dec48f8024fa82003ce
COCOAPODS: 0.29.0
Where an error message would be super useful for a lot of people.
This is opened as a duplicate of CocoaPods/CocoaPods#1847 as the issue would be better fixed here in core.
//cc @orta
This means that the framework should:
@rpath
.Currently you have to do the following:
s.osx.vendored_framework = "PLCrashReporter-1.2-rc2/Mac OS X Framework/CrashReporter.framework"
s.osx.resource = "PLCrashReporter-1.2-rc2/Mac OS X Framework/CrashReporter.framework"
s.osx.xcconfig = { 'LD_RUNPATH_SEARCH_PATHS' => '@loader_path/../Frameworks' }
Somewhat related to #57.
Seems like there is an error when linting a spec that points to gist.github.com. Even when the spec points to the https
link the validation fails. Lint output https://travis-ci.org/CocoaPods/Specs/builds/13016103#L169 for spec https://github.com/timshadel/Specs/blob/d9d26c59d80cf63ac121419371f32380b1c6a8ce/UIImageEffects/0.0.1/UIImageEffects.podspec
I shouldn't have to write the following (well, regex it from the lockfile) in order to exclude a single subspec which has a broken dependency:
pod 'libextobjc/EXTADT'
pod 'libextobjc/EXTAnnotation'
pod 'libextobjc/EXTBlockMethod'
pod 'libextobjc/EXTBlockTarget'
pod 'libextobjc/EXTConcreteProtocol'
pod 'libextobjc/EXTDispatchObject'
pod 'libextobjc/EXTFinalMethod'
pod 'libextobjc/EXTKeyPathCoding'
pod 'libextobjc/EXTMaybe'
pod 'libextobjc/EXTMixin'
pod 'libextobjc/EXTMultimethod'
pod 'libextobjc/EXTMultiObject'
pod 'libextobjc/EXTNil'
pod 'libextobjc/EXTPassthrough'
pod 'libextobjc/EXTPrivateMethod'
pod 'libextobjc/EXTProtocolCategory'
pod 'libextobjc/EXTSafeCategory'
pod 'libextobjc/EXTScope'
pod 'libextobjc/EXTSelectorChecking'
pod 'libextobjc/EXTSwizzle'
https://api.github.com/repos/CocoaPods/Specs/git/trees/HEAD?recursive=1
PL #77 introduced a bug when linking private specs with sources under [email protected]:cocoapods/EnterpriseKit.git
. We are using self-hosted GitLab instance and it's not possible to use HTTP without authentication. Storing credentials or OAuth token does't seem to be good idea.
I'm not sure if it's possible to use https://TOKEN:[email protected]/COMPANY/REPO.git
like format in GitLab
As far as I understand putting semicolon after host name violates RFC2396, so we need to find other way to validate URIs here.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.