Getting Started with CocoaPods and Cloudsmith

Cloudsmith now supports CocoaPods. This short demo shows how easy it is to get started with your own private CocoaPods repository.

https://help.cloudsmith.io/docs/cocoapods-repository

At Cloudsmith we are proud to be cloud-native. We’re building a universal cache that really delivers in terms of accelerating software development and distribution, and we don’t believe that is possible with conventional on-prem solutions.

These days multiple teams in locations all over the globe are absolutely typical in software development. 

Those teams and individuals need a single source of truth and they need consistent, reliable delivery wherever they are

. And for us, it feels obvious that the cloud is the only sensible way to deliver that type of service.

Thankfully our customers agree. They trust us enough to put Cloudsmith at the heart of their CI and deployment pipelines. In that context, performance - how fast it takes to fetch a package - is vitally important. When hundreds or thousands of packages need to be integrated into a build, small delays quickly compound into critical and irritating eternities.

We don’t want that to happen to our customers, and we don’t believe they should sacrifice anything in performance. We are always working as hard as possible to make cloud-native package management as fast and performant as possible.

To that end, we’ve been busy over the last week rolling out new product features that make the cloud feel and perform as if it was right there in the building with you - specifically 

Many of our customers want control over exactly where the packages they use are stored. This might be due to regulatory or compliance reasons, or simply a desire to keep intellectual property within a specific jurisdiction, for all sorts of easy to understand reasons

Thanks to our cloud-native approach and our custom storage options, they can do just that, and choose precisely where packages within the Cloudsmith infrastructure are stored.

Of course storing packages closer to where your services and teams operate can also provide significant performance benefits and lower latency in many cases - and particularly for cold fetches. That makes things fast, but at Cloudsmith ‘fast’ isn’t good enough. As mentioned above we want the cloud to feel like home - and the modern DevOps processes we integrate with demand it.

That’s why we’ve gone one step further in terms of both control and performance.

The closer your packages are to your teams and processes, the better. It’s as simple as that. And no amount of optimization in our code (and there is plenty in there) can defeat the laws of physics. As a result, requests that have to cross half of the planet are always going to take hundreds of milliseconds no matter what you do.

Cloudsmith addresses this issue by supporting the caching of artifacts and packages as close to the team as possible (and for multiple teams in multiple locations simultaneously). Using Lambda@Edge, an Amazon platform that combines the Cloudfront CDN platform with Lambda’s serverless processing capabilities, we shave off a large chunk of latency by moving critical computation closer to our customers and removing the need for requests to cross the world in many cases.

To repeat: that can really make a difference.

 We have a number of customers in Australia, and even before we take application latency into account we're dealing with a 280ish ms round trip time between Ireland and Oz, on even the most optimal of network links.

we now give customers the ability to configure edge caching settings for themselves

. In other words, we give full control over how long packages are cached, and allow different package types to be cached for different periods of time - and those rules are entirely flexible.

Time-to-live (TTL) is entirely customizable, meaning packages that change infrequently can be stored in the cache for extended periods of time (with consequent performance improvements), whereas those that are frequently updated can be automatically updated on a more frequent basis to ensure the cache is always serving the latest and correct version.

Ultimately, it’s about both performance and control. With the ability to define edge caching rules, our customers control how long assets stay close to their users, all across the world. Edge cached assets will be immediately available for use with minimal time required to fetch them.

Reduced latency, better throughput, high availability.

If you want to get started with Cloudsmith, it takes just 60 seconds to set up and start using your own private repository. You can make that happen 

We’re Making The Cloud Faster With Local Storage And Edge Caching

The subject of containers probably doesn’t need much of an introduction. Since the launch of Docker in 2013 containers have become almost ubiquitous, with 

 confirming their organizations used containers in some way during 2019.

That is no surprise. Docker itself calls the container “a standardized unit of software”, which is a nice way of saying that a typical container packages up all the relevant code, system tools, dependencies and libraries within an application, and effectively isolates that application from the rest of the environment and infrastructure.

As a result, containers have one great merit: they will reliably run, and run in the same way, wherever they are deployed. At a stroke, they eliminate the “well it’s working on my machine” problem that has caused endless heartache for both development and operations teams over the decades.

That benefit should not be under-estimated.

 For developers in particular, it is rather wonderful to be able to put everything into a container and throw it over the wall 

 that it is going to deploy, and in turn knowing that it isn’t going to come back over the same wall for round 2.

It’s also - at least in theory - good for the operations team as well, for all of the same sorts of reasons.

What Is A “Unit” Of Software, Really?

Prompted by the Docker definition of container I mentioned above, it might be instructive to ask ourselves whether the container is either the only, or indeed the best, ‘unit’ of software.

If we take a 10,000 ft view of the history of software development it probably looks something like this:

The entirety of the source code is the unit

In the old days of source code you really had to be on top of things. The whole thing stood up or fell over as a whole, and things were pretty painful and expensive if (when) it did the latter.

When the package became the unit, things improved

. Certainly, if we were following good package management and distribution best practices, then in most cases things fell over less, and were easier to fix when they did. I’ll talk more about this later, but let’s also remember that packages also help speed up development full stop as they enable us to more easily re-use code and services.

In the move to containerization, the third stage in our evolution, the ‘unit’ of software has got bigger. As it has done so, it has concealed complexity in order to enable that crucial isolation from the environment it runs.

Essentially, the container runs as a kind of black box. The operations team just need to know what it does. They don’t need more detailed metadata and they don’t need to know what is inside it. After all, it’s all one self-contained package. So the unit of sofware has not only got bigger, it has also become less transparent.

The problem with a large unit size is that within it are likely to be hundreds if not thousands of dependencies.

And the problem with being opaque is that we don’t know what they are.

What happens when something goes wrong? Let’s imagine (and this won’t take too much effort for veterans of 

 or one of any number of dependency related screw-ups) that a vulnerability is discovered within a certain package.

Where is that package currently in use in our ecosystem? We don’t know. Can we quickly roll that package back to a known ‘safe’ version wherever necessary? No.

Containers - as a ‘unit’ of software - live or die as a whole

. If something is wrong, or might be wrong, we have no option other than to spin up a new version and redeploy: not necessarily a simple task. And as we don’t necessarily know which containers are affected, we find ourselves struggling to get on top of an emerging security crisis based on limited data. Not a nice place to be.

My last point is this: that containerization has led to a general decline in diligence and observance of best practices when it comes to handling packages and dependencies. After all, if I am going to throw them all into one container and check if it runs does it really matter where I get packages from?

The longer answer is yes, because if we aren’t going to be sure what is in any given container further down the line, we should be as careful as we possibly can be that nothing we can’t stand over sneaks in now.

Unfortunately, that doesn’t always happen. The path of least resistance is to get dependencies from pretty much anywhere and live with the consequences later. And as the developer cares about speed, and the ops team will be the ones dealing with those consequences, there is all the more reason to cut corners.

As developers, we need to get back to being diligent - and consistently diligent - about questions of security, provenance, reliability and availability when it comes to packages and dependencies

. We need to be as sure as we can be that what we integrate into our projects (whether destined for containers or not) is what it says it is. And we need to know what we used where and when - so that we can fall back to a previous version quickly and easily if necessary.

It’s the least our colleagues in operations, and the users of our end product, deserve.

Did We Lose Something With The Adoption Of Containers? And Can We Get It Back?

For those who like to learn by watching, our resident talker Dan McKinney has pulled together a short video demonstrating exactly how to set up and use private Dart repositories using Cloudsmith:

Building Private Dart Repositories With Cloudsmith

It's easy get started with Dart and Cloudsmith, and deliver universal, secure and performant package management that helps accelerate software development and distribution.

Getting Started With Dart: A Video Guide


The promise of Cloudsmith is simple. We ensure development teams have access to the packages they need, when they need them.

And we do that through a private, cloud-based repository that can help shield the business from malware, security and licensing concerns related to the use of third party software packages, whilst giving you total control over access to your own packages.

. We understand that individual developers and teams work in multiple languages and with multiple package formats. We allow them to continue to do just that, but handle package management in a consistent, reliable and performant way through Cloudsmith.

Today, as part of that commitment, we’re launching support for private Dart package repositories.

 is an open-source, object-oriented, general-purpose programming language developed by Google. It is a client-optimized language for building fast apps on any platform, focused on providing a productive environment for developers new to the web, especially developers comfortable with structured languages and tools.

Since 2013, Google has implemented websites such as AdWords and Google Fiber using Dart, and in 2017, we saw the release of 

; Google’s UI framework for building native interfaces in iOS and Android, which is built on top of Dart.

The popularity of Flutter has spurred a revival of Dart's usage for mobile development, a process accelerated by the roll-out of Dart 2.0, which featured improvements to client-side development, including strong typing and “

”. Dart also appears to be popular with those who use it. In 2019 the 

y found that 66.3% of those using Dart would continue to use it in future - putting it firmly in the ‘loved’ category.

 programming language, containing reusable libraries & packages for Flutter and general 

As most readers will know, packages allow code-sharing and reusability across Flutter/Dart apps. Pub is responsible for downloading and installing these packages, mostly from pub.dev, the 

But you don’t have to use pub.dev. Pub provides all the necessary tooling and configuration flags to point at another repository if needed.

And there are several great reasons you may wish to do exactly that - and run your own private repository on Cloudsmith. Taking this approach allows development teams to:

Develop Dart packages internally and share them privately to other teams.

Distribute and deploy your own Dart packages in a pipeline at your org.

Distribute Dart packages as commercial software.

Make modifications to public Dart packages, without republishing publicly.

Mirror public Dart packages and isolate from uncontrolled upstream issues.

Capture the exact state of your dependencies at a particular version/release.

Control (whitelist/blacklist) the exact Dart packages allowed for your org.

Keep track of the exact versions/releases of Dart packages you have/use.

In short: deliver all the benefits of Cloudsmith that are already enjoyed by development teams all over the world today.

 to begin hosting and distributing your Dart packages at the world's first hosted private Dart package repository service.

Getting started with Cloudsmith and Dart couldn't be simpler.

 and a repository to which you can upload packages. Secondly, you'll need to ensure you're running at least version 2.0 (or later) of Dart.

You can check your currently installed Dart and Pub versions like so:

If you see something like the above, you're ready to go!

For the purposes of this demonstration, we will create a dart file containing a single function that prints a message, and a pubspec file used to create a package.

If you take a look inside the new directory where you created these files you'll see the following:

At present, the native tooling does not support generating a package but it can be used to validate the 

To create the package, we will use tar to copy all files into a 

. In this example, the only files that exist are our pubspec and dart file however it's important to exclude any unnecessary files.

Once built you can push the package to Cloudsmith using the 

. We don't yet support pushing packages with pub publish, but we'll be adding support in a future release (if you want it, please let us know). For now, use the CLI.

Publishing your Dart packages to Cloudsmith

First, ensure you've installed the Cloudsmith CLI and configured authentication:

Then, use the CLI to push the package, which operates like pub publish but is specific to Cloudsmith:

Your repository should now contain the uploaded package. An example of which is our official Cloudsmith examples repository (this is where we upload 

Installing your Dart packages from Cloudsmith

First, we need to tell Pub how to access the repository. To do so you need to add the following entry in your 

 with an entitlement token, which is a type of read-only authentication token that we support)

You can install packages from the command line:

It really is that simple, and now you've sourced a Dart package privately from your very own private Dart repository on Cloudsmith. Well done!

Cloudsmith provides fully featured Dart repositories on all plans, flexible enough for use whether you’re hosting public packages for a public or open-source project, or private packages for your company’s internal needs. We're extremely proud to be able to support the Dart ecosystem with this first (non-official) implementation of public and private Dart packages.

You can find further, context-specific information, including detailed setup and integration instructions inside each Cloudsmith repository. You can see an example of this documentation in our public examples repository.

Get your public and private Dart repository hosting at Cloudsmith now

Cloudsmith Launches World's First Private Dart Repository Service

We can't say it enough. We have the best customers. We have an incredible support network in Belfast, Dublin, London and San Francisco. None of Cloudsmith's success in 2019 would have been achieved without 

Alan, Lee, Peter & the team at Cloudsmith.


By The Numbers (2019)

At Cloudsmith, our goal is to make it as easy as possible to get your packages into our system from where you can manage and distribute them according to your needs.

CircleCI is a continuous integration and delivery platform that helps teams release quality code, faster. They provide a mechanism for users to share code and libraries which can be reused across pipelines called "orbs".

Cloudsmith provides first-class support for CircleCI with our official 

. Using the orb, users can easily integrate publishing to Cloudsmith with their existing CircleCI workflows.

Full reference documentation for the orb can be found on the 

. This documentation is automatically generated from the orb itself and so is guaranteed to always be up to date with the latest release of the orb.

To use the orb you must first ensure you are using Circle version 2.1. At the top of your 

You'll need to configure authentication credentials for the orb. To do so, you can add an environment variable named 

 within the CircleCI settings page for your project:

The orb (for now) requires that you have already built the package you wish to publish. Assuming you're publishing a Python library (though the same process applies to any package type), you'll want to run 

Once built, we can use the orb to easily publish the package. The orb provides a number of commands to make this process simpler. We'll first ensure the Cloudsmith CLI is configured and installed, then after we've built the package, publish it:

Putting this all together, we end up with a 

Our official orb provides simple integration for the majority of standard CI usecases, but we know that it won't fit every purpose. For additional flexibility users can mix and match commands provided by the orb and/or use the Cloudsmith CLI directly.

For example, to use the orb to install and configure the CLI, but then use the CLI directly to publish to Cloudsmith, your configuration might look like so:

As always, if you have any questions about integration or would like some general advice, please 