-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Private Spec Repos #12
Comments
This is one of those things where an "official" recommendation will not solve everyone's problems. I think the best case here is to have both, and list some pros/cons. The section on using private pods with |
Just my two cents here: we are using private specs repos in our company because we are developing some internal components that we keep on the shelf to reuse in some projects, but those components are private to the company and not OpenSource so we don't want to put them in GitHub and push their specs on trunk & CocoaPods/Specs. Those components don't evolve that much (once we have a stable version, we of course have some enhancements and evolutions but maybe monthly, so far from daily). We use the GitFlow branching model, the master branch is locked on our GitLab and users are submitting evolutions with Pull Request, so that I (the designated iOS expert) or some other qualified iOS devs can review the code and validate (or not) the evolution. When someone submit a PR with changes in the code, they also modify the podspec file (at the root of the same repo), and when we accept and merge the PR, we simply have to create the GIT tag and run As a conclusion, Private Specs Repos are then a really useful feature for us. |
@AliSoftware I was doing things the same way until I saw @supermarin's talk. He brought up the following point: What is the benefit that your private pod `CompanyPrivateLibrary`, :git => 'git@github.com:Company/PrivateLibrary', :tag => '1.0.0' By having a private Especially if you're using CI as @mtitolo mentioned, if you run a Perhaps the one downside of getting rid of the private pod `...`, :git => '...', :tag => '~> 1.0' |
Right, you give up almost entirely on the power of dependency resolution, and I don't think that loss should be understated. |
@eric-horacek I have multiple benefits:
On the contrary when binding the Podfile to a specific and pinned tag, they have to know the exact tag, they can't use open restrictions on the version to use ( For us, CocoaPods is sure a library manager that ease the integration of external libraries, but is also and most especially a dependency manager and resolver. When specifying explicitly a repo and tag instead of relying on a Private Specs repo, we loose all those features that are what makes CocoaPods such a great tool.
We never |
Exactly my point. That is what makes all the power of CocoaPods, and I wouldn't miss these features for all the world. |
This may be question larger than the scope of this conversation, but why should a Specs repo be required for dependency management & resolution? Why can't the tags on the repo be interpreted as semantic version numbers? Is it simply because they aren't forced to follow the semantic version specification format? If that's the case, can ones that don't follow this specification format simply be ignored? |
Because cocoapods is not git specific. -Samuel E. Giddins On Jun 4, 2014, at 2:07 PM, Eric Horacek notifications@github.com wrote: This may be question larger than the scope of this conversation, but why should a Specs repo be required for dependency management & resolution? Why can't the tags on the repo be interpreted as semantic version numbers? Is it simply because they aren't forced to follow the semantic version specification format? If that's the case, can ones that don't follow this specification format simply be ignored? — |
Moved from CocoaPods/CocoaPods#2217
@eric-horacek asked:
@supermarin:
Michele has given a great intro on how to start and explained how this works. My talk was more on 'optimizing' and daily use-cases from the real life.
Personally - maintaining a private spec repo seemed like an overhead, because we always needed to push both source code and specs every time we updated any of the shared code. There's 15+ developers working on the code daily, so you can have an idea of how often does this happen.
Your quote has the same point:
We are still using private pods, but directly accessed via
:git => 'path'
.For the linking part, we do have all the unit tests that would catch any failure with it.
The text was updated successfully, but these errors were encountered: