text:
# Electron CGI

[Electron CGI](https://www.blinkingcaret.com/2020/03/25/electroncgi-1-0-cross-platform-guis-for-net-core/) is a library that enables creating requests in NodeJs that are then served by .NET.

The npm package is called [_electron-cgi_](https://www.npmjs.com/package/electron-cgi).

The nuget package is called [ElectronCgi.DotNet](https://www.nuget.org/packages/ElectronCgi.DotNet/#).

Here's an example of how you can interact with a .Net application from Node:

In NodeJs/Electron:

    const { ConnectionBuilder } = require('electron-cgi');

    const connection = new ConnectionBuilder()
            .connectTo('dotnet', 'run', '--project', 'DotNetConsoleProjectWithElectronCgiDotNetNugetPackage')
            .build();

    connection.onDisconnect = () => {
        console.log('Lost connection to the .Net process');
    };

    connection.send('greeting', 'John', (err, theGreeting) => {
        if (err) {
            console.log(err);
            return;
        }
        console.log(theGreeting); // will print "Hello John!"
    });

    //or using promises

    const theGreeting = await connection.send('greeting', 'John')

    connection.close();

And in the .Net Console Application:

    using ElectronCgi.DotNet;

    //...
    static void Main(string[] args)
    {
        var connection = new ConnectionBuilder()
                            .WithLogging()
                            .Build();

        // expects a request named "greeting" with a string argument and returns a string
        connection.On<string, string>("greeting", name =>
        {
            return $"Hello {name}!";
        });

        // wait for incoming requests
        connection.Listen();
    }

### How does it work?

Electron CGI establishes a "connection" with an external process. That external process must be configured to accept that connection. In the example above that's what the `Listen` method does.

In Node we can "send" requests (for example "greeting" with "John" as a parameter) and receive a response from the other process.

The way this communication channel is established is by using the connected process' stdin and stdout streams. This approach does not rely on staring up a web server and because of that introduces very little overhead in terms of the requests' round-trip time.

## Changelog

## Update version 1.0.3

Bugfix for `Connection.Send(requestType, arg, responseArg => {...})` where argument type information for the response argument type was being inadvertently discarded.

## Update version 1.0.2

Added the the `UsingEncoding(System.Text.Encoding encoding)` method to `ConnectionBuilder`, usage:

`var connection = new ConnectionBuilder().UsingEncoding(System.Text.Encoding.UTF8).Build()`

If you are having encoding issues with messages between Node and .NET failing because of special characters (e.g. ä,ö,ü) try to set the encoding this way in .NET.

## Update version 1.0.1

- Error propagation to Node.js

    - An exception in a handler will be serialized and sent to Node.js (requires electron-cgi 1.0.0) and won't crash the process

- Bugfixes

## Update version 1.0.0

- This version was uploaded incorrectly. Skip it.

## Update version 0.0.5

- Duplex: ability to send requests from both .Net and Node.js

## Update version 0.0.2
- Ability to serve request concurrently (uses System.Threading.Tasks.DataFlow)

### Next steps
- Add the ability to send requests form .Net to Node
- Instead of making the process fail when there's an exception in a handler, serialise the exception and "surface" it in Node
___________


text:
# medcodeassist
Assistant for medical coding based on analysis of free text medical documentation

## API

### Tokenizations

Expects
- text

Returns
- list of {word, token, pos}

### Synonyms
Expects
- word
- count (of expected synonyms. Only makes sense because we are approximating synonyms by similar tokens. Will be removed when we switch to a real synonym database)

Returns
- list of simlar tokens ({name, similarity})

Note: At the moment we're approximating synonyms by using a similarity measure.

### Code Proposals
Expects
- list of input_codes and input_code_types (i.e. input_codes[i] has the type input_code_types[i])
- get_drgs, get_chops, get_icds (E.g. set get_drgs to true if you want a list of drgs. You can retrieve multiple types of codes at the same time.)
- count (How many codes per type you want to retrieve)

Returns
- list of {code, similarity}

license: MIT

repository: Masterxilo/medcodeassist

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: Masterxilo/medcodeassist


text:
---
layout: post
title:      "React Project"
date:       2020-08-17 08:47:26 +0000
permalink:  react_project
---

For my react project, I decided to develop a Netflix clone. This project was the most rewarding yet. I was so amazed at all the skills I learned during the last few months. There is so much more I would like to add to make the website function similar to Netflix. One of my next features would be to add movie trailers. The biggest challenge I faced while building this project was to render the correct movie to the show page with Dynamic Routing with React Router. Overall this project taught me a lot, I'm excited to have made it this far into my coding journey and I can't wait to learn more.

extension: markdown


text:
# how to use

Every sub directory produces one document (a beamer presentation in pdf).
The example is 120_java_bindings, which should produce the topic on java bindings, which is about java beans and javafx bindings, the modern variant that is used throughout javafx.

For building we use script, called msheets.
This should preferbly in the path.
The scripts are in .../latexstuff/bin
.

repository: sebivenlo/latexstuff

gha_language: TeX

repo_name: sebivenlo/latexstuff


text:
# Eslint Watch

[![](https://img.shields.io/badge/release-notes-blue.svg)](https://github.com/rizowski/eslint-watch/releases/latest)
[![Build Status](https://travis-ci.org/rizowski/eslint-watch.svg?branch=master)](https://travis-ci.org/rizowski/eslint-watch)
[![Code Climate](https://codeclimate.com/github/rizowski/eslint-watch/badges/gpa.svg)](https://codeclimate.com/github/rizowski/eslint-watch)
[![Dependencies](https://www.versioneye.com/nodejs/eslint-watch/reference_badge.svg?style=flat-square)](https://github.com/rizowski/eslint-watch/network/dependencies)

Don't want to import Webpack, Grunt, or some other task package into your project? Then this is the tool for you.
Eslint Watch is a simple command line tool that wraps [Eslint](https://www.npmjs.com/package/eslint). Eslint Watch provides file watching and command line improvements to the currently existing Eslint command line interface. All commands that Eslint offers can be used with the addition of a watch command and a couple new templating views. Don't believe me? Checkout the [code](https://github.com/rizowski/eslint-watch) or some of the features below!

## Requirements

To use this tool we require eslint to be installed on your project. The versions supported are:

- `"eslint": ">=8 <9.0.0"`
- `node >= 12.0.0 <= LTS` Non LTS versions will have limited support.

## Getting started

To run eslint-watch without the global install, make an npm script.

### Installing

- `npm i -g eslint eslint-watch` or `npm i -D eslint eslint-watch`
- `yarn global add eslint eslint-watch` or `yarn add -D eslint eslint-watch`

## Features added

- Watching
  - Multi-directory watching
  - Runs a full directory lint before the watch
  - Press `enter` to rerun directory lint while watching
  - Include directories to ignore on watch
- Eslint Overrides
  - Default directory linting. A directory is no longer required.

## Options/Usage

Eslint-Watch replaces only a few commands that it needs to take control over. All other commands are forwarded to Eslint unmodified. Please refer to their help text for full command support as the one provided below might not be up to date with the latest Eslint changes.

```md
esw [options] [file.js ...] [dir ...]

ESW Options:
  -h, --help                     Show help
  -w, --watch                    Enable file watch
  --changed                      Enables single file linting while watch is enabled
  --clear                        Clear terminal when running lint
  -v, --version                  Prints Eslint-Watch Version
  --versions                     Prints Eslint-Watch and Eslint Versions
  --watch-ignore RegExp          Regex string of folders to ignore when watching - default:
                                 /.git|node_modules|bower_components|.eslintcache/
  --watch-delay Int              Delay(ms) for watcher to wait to trigger re-lint - default: 300

Basic configuration:
  --ext [String]                 Specify JavaScript file extensions - default: .js
  --no-eslintrc                  Disable use of configuration from .eslintrc.*
  -c, --config path::String      Use this configuration, overriding .eslintrc.* config options if present
  --env [String]                 Specify environments
  --global [String]              Define global variables
  --parser String                Specify the parser to be used
  --parser-options Object        Specify parser options
  --resolve-plugins-relative-to path::String  A folder where plugins should be resolved from CWD by default

Specifying rules and plugins:
  --rulesdir [path::String]      Use additional rules from this directory
  --plugin [String]              Specify plugins
  --rule Object                  Specify rules

Fixing problems:
  --fix                          Automatically fix problems
  --fix-dry-run                  Automatically fix problems without saving the changes to the file system
  --fix-type Array               Specify the types of fixes to apply (directive problem, suggestion, layout)

Ignoring files:
  --ignore-path path::String     Specify path of ignore file
  --no-ignore                    Disable use of ignore files and patterns
  --ignore-pattern [String]      Pattern of files to ignore (in addition to those in .eslintignore)

Using stdin:
  --stdin                        Lint code provided on <STDIN> - default: false
  --stdin-filename String        Specify filename to process STDIN as

Handling warnings:
  --quiet                        Report errors only - default: false
  --max-warnings Int             Number of warnings to trigger nonzero exit code - default: -1

Output:
  -o, --output-file path::String  Specify file to write report to
  -f, --format String            Use a specific output format - default: stylish
  --color, --no-color            Force enabling/disabling of color

Inline configuration comments:
  --no-inline-config             Prevent comments from changing config or rules
  --report-unused-disable-directives  Adds reported errors for unused eslint-disable directives

Caching:
  --cache                        Only check changed files - default: false
  --cache-file path::String      Path to the cache file. Deprecated: use --cache-location - default: .eslintcache
  --cache-location path::String  Path to the cache file or directory
  --cache-strategy String        Strategy to use for detecting changed files in the cache - either: metadata or content - default:
                                 metadata

Miscellaneous:
  --init                         Run config initialization wizard - default: false
  --env-info                     Output execution environment information - default: false
  --no-error-on-unmatched-pattern  Prevent errors when pattern is unmatched
  --exit-on-fatal-error          Exit with exit code 2 in case of fatal error - default: false
  --debug                        Output debugging information
  --print-config path::String    Print the configuration for the given file
```

### Other Options

Eslint-Watch uses [`chokidar`](https://github.com/paulmillr/chokidar) under the hood to watch for changes. Chokidar can be configured to poll for changes (this might be necessary if you are running Eslint-Watch inside a VM or Container) by setting the `CHOKIDAR_USEPOLLING` environment variable to `true`.

## Functionality

[![Simple lint and watch](https://thumbs.gfycat.com/AgreeableForsakenIvorygull-size_restricted.gif)](https://fat.gfycat.com/AgreeableForsakenIvorygull.gif)

Donate:

- (Ƀitcoin): `13V7iDxBhnFASw7avGGRk64ExDGTirhx37`

- (PayPal): [https://www.paypal.me/rizowski](https://www.paypal.me/rizowski)

repository: rizowski/eslint-watch

gha_language: JavaScript

gha_license_id: MIT

repo_name: rizowski/eslint-watch


text:
---
title: promql package
description: >
  The `promql` package provides an internal API for implementing PromQL via Flux.
menu:
  flux_0_x_ref:
    name: promql
    parent: internal
    identifier: internal/promql
weight: 21
cascade:

  introduced: 0.47.0
---

<!------------------------------------------------------------------------------

IMPORTANT: This page was generated from comments in the Flux source code. Any
edits made directly to this page will be overwritten the next time the
documentation is generated.

To make updates to this documentation, update the comments above the package
declaration in the Flux source code:

https://github.com/influxdata/flux/blob/master/stdlib/internal/promql/promql.flux

Contributing to Flux: https://github.com/influxdata/flux#contributing
Fluxdoc syntax: https://github.com/influxdata/flux/blob/master/docs/fluxdoc.md

------------------------------------------------------------------------------->

The `promql` package provides an internal API for implementing PromQL via Flux.
Import the `internal/promql` package:

```js
import "internal/promql"
```

**Important**: This package is not meant for external use.

## Functions

{{< children type="functions" show="pages" >}}


text:
---
id: 117
title: Farewell Harriet, Hello Rachel
date: 2020-10-05T12:03:12+00:00
guid: https://www.serenadewind.com/posts/harriet-rachel/
permalink: /posts/harriet-rachel/
author: sw
layout: post
categories:
    - Relationships
    - Minimalist Living
tags:
    - powerofwhy
    - lifereset
    - transitions
    - coronavirus
    - shelterathome
    - tbt
share: true
image:
    thumbnail: /images/small/dhn-harriet-living-room.jpg
excerpt: When we returned from Florida, we spent an exhausting week packing and loading the POD. Why is it that when we had 20% left to go, it was so much harder than going through the initial 80% of our stuff? Here is an update on how we stand in the final weeks of our 30-weeks to minimalism plan.
---
{% include toc %}

{% assign pwimg="dhn-hsu-family-chris-wedding" %}
{% assign pwcaption="Hsu family, March 2019" %}
{% assign pwpng="" %}
{% include post-wide-image.html%}

# We don't need calligraphy

Back in July, a few members of the extended Hsu family descended on our home to catch up on life, chow on some dim sum and reminisce about the past. Over the decades, it seems the only time we get together was for life events such as weddings, births and more recently funerals.

Before cousin Christopher's wedding ceremony in March 2019, my cousins and I remarked how the Hsu family could rally at a moment's notice. We don't need calligraphy. We don't need engraved invitations. We really don't bother too much with formalities or social protocols. When we hear a call to action, we drop whatever we're doing, we hustle and we show up early. This was especially true when Andrew and I were married within a few weeks of announcing the date.

Back then, breaking news came via the "Mom network," which dispatches the word throughout the extended family. Because Andrew and I had news which seemed to impact our generation more readily, I dispatched the "Cousin network" to let the family know of our plans. Within days, they gathered in small groups wearing masks in our home on Harriet Lane to help out with whatever we needed.

{% assign pwimg="dhn-harriet-living-room" %}
{% assign pwcaption="" %}
{% assign pwpng="" %}
{% include post-wide-image.html%}

# Call to action

Once the word got out, many of the Hsu cousins (and there's 12 of us!) as well as aunties came over with loads of food and offers of assistance.

 - Cousin Paul, his wife Lauren and daughter Abby along with his mom Aunt Lily were the first to came over. They volunteered to help with some logistics and some future product launches for Serenade Wind. Throughout the afternoon, Aunty and Abby could be seen walking from room to room in search of Xiaolong.

 - His younger sister, cousin Ellen, also came over to drop off photos from our wedding as well as find out more about our plans and find a home for many of our belongings.

 - Cousin Janet came a few days later and offered to foster Xiaolong while we were travelling. By the end of the week, her husband Edi and her daughters Sabrina and Veronica also came to meet Xiaolong.

 - Before the weekend was out, we also had a chat with cousin Grace's husband Gary who gave us some tips on ocean fishing, trawling lines and gifted us some of his fishing gear to get us started.

Our friends who we consider family as well have also pitched in to help, including Hasmik, Jenny & Danny, Helen & Mar, Nick & Brit, Jason & Yoko, JC & Camille, Linda & Edwin, Subu & Sandhya, Bill, Palace and others.

{% assign pwimg="dhn-harriet-piano-move" %}
{% assign pwcaption="" %}
{% assign pwpng="" %}
{% include post-wide-image.html%}

Within a few short weeks, cars, furniture and odds & ends were earmarked for new homes with a near-term plan to move as much out of Harriet Lane over Labor Day weekend or earlier.

As you may recall, I was frustrated over the lack of progress we were making on downsizing and purging. However, as I sat one morning reviewing our [bullet journal](/posts/eye-of-the-storm/) and the [30-weeks to Minimalism](/posts/30-weeks-to-minimalism/) plan, I counted out the weeks.

 - Week 3 - how to tackle [sentimental items](/posts/throw-back/)
 - Week 6 - [what clothes](posts/packing-light/) should you bring for a cruising lifestyle and how many & what type of [linens](/posts/boat-head/) will we need on board
 - Week 7 - does a foodie need to sacrifice all her [kitchen gadgets](/posts/sea-foodie/) and what do we need for the [rest of the space](/posts/sea-foodie/)?
 - Week 12 - once you've narrowed down what you want to take, here are some [strategies to upcycle](/posts/matching-gifts/) your stuff
 - Week 15 - don't forget to deal with your [digital assets](/posts/shutterbug/)

Fifteen weeks after the 30-weeks to minimalism post went out (April 20th), we had a plan for [giving](/posts/matching-gifts/) or selling a significant amount of our stuff. By week 20, 80% of the stuff would be gone.

Why did we delay moving the bulk of these items for another month?

{% include responsive-embed url="https://www.youtube.com/embed/gpbmAR4CsPY" ratio="16:9" %}

# Xiaolong Mao

The primary reason was our tuxedo cat, Xiaolong (a.k.a. [Little Dragon](https://bruceleefoundation.org/littledragons/), a.k.a. [Dumpling](https://en.wikipedia.org/wiki/Xiaolongbao)).

Earlier in the summer, we detected some personality changes as we began to pack up boxes, throw away or recycle items, and move furniture around. Even before the first of the furniture was sold early July, Xiaolong started to exhibit nervousness and hide when people would come over. He never did that before. For the past 5 years, he was a friendly and sociable kitty, greeting our friends when they came over for barbeques.

Not anymore.

Andrew recounted a previous experience with his two Himalayan cats, Manny and Moe. When the last stick of furniture was moved out of his parents' house, the kitties would run headlong into walls over their torment. We suspect it was because their environment had changed so drastically.

Given this backdrop, we wanted to come up with a plan that kept Xiaolong from prolonged anxiety. We decided to find him a home quickly, so he can go back to being his normal self: trilling in the hallways, hunting bugs, and napping in the sun.

On August 12, Janet and her family came over and picked up Xiaolong along with a lot of gear. For the first time in my life, I experienced the "empty nest" feeling many talk about. Less than 2 days later, he was exploring each of the rooms in his new home and making all kinds of funny noises. What a relief it was to hear that.

Before heading to Florida for [the survey and sea trial](/posts/survey-sea-trial-part-2/), I wanted to visit Xiaolong in his new home. It had been a month and I missed him every day, though not as much when we were in [Seattle with Emma and Silvia](/posts/seattle/). When we arrived, he was friendly and curious as he usually was with strangers. He behaved as if he had no memory of living with us since he was a kitten.

Realizing that, I knew I would be the only one to remember the bond we shared. I scooped him up, gave him a belly kiss, and said goodbye.

{% assign pwimg="dhn-49-sq-ft-minimalism" %}
{% assign pwcaption="7x7 sq ft" %}
{% assign pwpng="" %}
{% include post-wide-image.html%}

# 7 x 7

Looking around Harriet Lane, we realize that we no longer have a living room, dining room and all the trappings of a typical, suburban life. Instead, we have a yoga studio, climbing gym, and skatepark. Our belongings which once filled a 3-bedroom, 2-car garage house is now reduced to 49 sq ft of space.

As our family and friends came over to visit us (appropriately masked during the pandemic), we showed them a couple taped off areas. The first one ran pretty much the length of the east wing of Harriet Lane. During Palace's visit, we taped off 50' LOA and 13'4" beam. This provided everyone the scale of [s/v Rachel J Slocum](/about-rachel-j-slocum/), while we described the location of the saloon, galley, and owner's stateroom.

The second area was the room where we had taped off 7x7 sq ft of space. Everything outside of the square must go to new homes or to charity. The only things we are keeping and taking with us to our sailboat is reflected inside this square. It blew their minds.

{% include sticky-note.html text="Reduce possessions" %}
{% include sticky-note.html text="Consolidate our stuff" %}

After 2 years of having written our goal on the [whiteboard](/posts/time-to-go-to-the-whiteboard/) on August 2018, we finally got a chance to get rid of all of our stuff. We have that light feeling that comes with an [empty backpack](/posts/sailing-around-the-world/) so we can begin to curate experiences and not possessions.

So we packed up 7x7 sq ft of possessions, loaded it all in a moving pod and shipped it to Florida.

{% include responsive-embed url="https://www.youtube.com/embed/6aEyCEg-p2Y" ratio="16:9" %}

# Farewell Harriet... Hello Rachel!

For those visually inclined, here are the highlights of how we became minimalists in less than 30 weeks. All it takes to become a minimalist: a bullet journal, tenacity and a willing partner in life.

repository: aniculescu/serenade-wind

gha_language: SCSS

repo_name: aniculescu/serenade-wind


text:
---
layout: default
title: The result - Documentation - sitespeed.io
description: Result from an analyze using sitespeed.io.
keywords: configuration, documentation, web performance, sitespeed.io
author: Peter Hedenskog
nav: documentation
image: https://www.sitespeed.io/img/sitespeed-2.0-twitter.png
twitterdescription: Result from an analyze using sitespeed.io.
---
[Documentation 3.x]({{site.baseurl}}/documentation/) / Result

# The Result
{:.no_toc}

* Lets place the TOC here
{:toc}

# HTML
The result of an analyze can be a couple of HTML pages, JUnit XML/TAP and you can
send the metrics to [Graphite](#graphite). Lets first checkout the different HTML pages.

## Site summary page

The summary page is a executive summary page where green is good, yellow means that you should look into it and red is bad (sometimes really bad). The page shows a summary of best practices for good web site performance (and site speed metrics if configured). You can choose which boxes/best practices that will be shown on this page, so you can create different views for different use cases.

![Site summary page]({{site.baseurl}}/img/site-summary-3.png)
{: .img-thumbnail}

## The detailed summary page

The detailed summary page will give you almost all the metrics you want for you site. You will get the average, 10th percentile, median, 95th percentile, min, max and standard deviation value for each metrics (this page is based on the **summary.json** file, where you also will find the variance and the 90th percentile, if ever needed when comparing metrics).

![Detailed site summary page]({{site.baseurl}}/img/detailed-site-summary-3.png)
{: .img-thumbnail}

## Detailed site report

The detailed site report page shows data collected for each page. You can configure which metrics/data that you want to show in the columns, so you can choose what is extra important for you.

![Detailed site report]({{site.baseurl}}/img/detailed-site-report-3.png)
{: .img-thumbnail}

## Full page analyzes

Every page that is tested, also get a corresponding HTML page, where all in deep data is shown. Checkout the [examples]({{site.baseurl}}/examples/) section to see what it looks like.

![Full page report]({{site.baseurl}}/img/full-page-report-3.png)
{: .img-thumbnail}

## Most used assets report
The most used assets report show you the most used assets (a.k.a which asset should you start to change to get the most bang for the money).

You will see the following for each asset: the type, the time since last modification, the cache time, the weight and the number of times the asset has been used.

![Assets report]({{site.baseurl}}/img/assets-report-3.png)
{: .img-thumbnail}

## Hotlist
The hotlist is a way of trying to find bad pages/assets that you should focus on to get better performance.

![Hotlist report]({{site.baseurl}}/img/hotlist-report-3.png)
{: .img-thumbnail}

## Domains
If you fetch timings using your browser, the domains page will be created, that shows timings per domain, making it easier to spot 3rd party domains that is slow.

![Domains report]({{site.baseurl}}/img/domains-report-3.png)
{: .img-thumbnail}

## Screenshots

You can choose to take screenshots of every tested page for the used viewport.

 That is good if you yourself want to harvest the data from the result.

# Graphite
Most of the collected metrics can be stored in Graphite, making it easy for you to graph the metrics. Checkout the [Graph section]({{site.baseurl}}/documentation/graphs/).

# TAP and JUnit XML
You can create TAP or JUnit XML from your analyze, head over to the [Continuous Integration section]({{site.baseurl}}/documentation/continuous-integration/#generating-junit-xml-or-tap).


text:
# Options

## Setting options

cibuildwheel can either be configured using environment variables, or from
config file such as `pyproject.toml`.

### Environment variables {: #environment-variables}

Environment variables can be set in your CI config. For example, to configure
cibuildwheel to run tests, add the following YAML to your CI config file:

!!! tab "GitHub Actions"

    > .github/workflows/*.yml ([docs](https://help.github.com/en/actions/configuring-and-managing-workflows/using-environment-variables)) (can be global, in job, or in step)

    ```yaml
    env:
      CIBW_TEST_REQUIRES: pytest
      CIBW_TEST_COMMAND: "pytest {project}/tests"
    ```

!!! tab "Azure Pipelines"

    > azure-pipelines.yml ([docs](https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables))

    ```yaml
    variables:
      CIBW_TEST_REQUIRES: pytest
      CIBW_TEST_COMMAND: "pytest {project}/tests"
    ```

!!! tab "Travis CI"

    > .travis.yml ([docs](https://docs.travis-ci.com/user/environment-variables/))

    ```yaml
    env:
      global:
        - CIBW_TEST_REQUIRES=pytest
        - CIBW_TEST_COMMAND="pytest {project}/tests"
    ```

!!! tab "AppVeyor"

    > appveyor.yml ([docs](https://www.appveyor.com/docs/build-configuration/#environment-variables))

    ```yaml
    environment:
      global:
        CIBW_TEST_REQUIRES: pytest
        CIBW_TEST_COMMAND: "pytest {project}\\tests"
    ```

!!! tab "CircleCI"

    > .circleci/config.yml ([docs](https://circleci.com/docs/2.0/configuration-reference/#environment))

    ```yaml
    jobs:
      job_name:
        environment:
          CIBW_TEST_REQUIRES: pytest
          CIBW_TEST_COMMAND: "pytest {project}/tests"
    ```

!!! tab "Gitlab CI"

    > .gitlab-ci.yml ([docs](https://docs.gitlab.com/ee/ci/variables/README.html#create-a-custom-variable-in-gitlab-ciyml))

    ```yaml
    linux:
      variables:
        CIBW_TEST_REQUIRES: pytest
        CIBW_TEST_COMMAND: "pytest {project}/tests"
    ```

!!! tab "Cirrus CI"

    > .cirrus.yml ([docs](https://cirrus-ci.org/guide/writing-tasks/#environment-variables))

    ```yaml
    env:
      CIBW_TEST_REQUIRES: pytest
      CIBW_TEST_COMMAND: "pytest {project}/tests"
    ```

### Configuration file {: #configuration-file}

You can configure cibuildwheel with a config file, such as `pyproject.toml`.
Options have the same names as the environment variable overrides, but are
placed in `[tool.cibuildwheel]` and are lower case, with dashes, following
common [TOML][] practice. Anything placed in subsections `linux`, `windows`,
or `macos` will only affect those platforms. Lists can be used instead of
strings for items that are naturally a list. Multiline strings also work just
like in the environment variables. Environment variables will take
precedence if defined.

The example above using environment variables could have been written like this:

```toml
[tool.cibuildwheel]
test-requires = "pytest"
test-command = "pytest {project}/tests"
```

The complete set of defaults for the current version of cibuildwheel are shown below:

```toml
{% include "../cibuildwheel/resources/defaults.toml" %}
```

!!! tip
    Static configuration works across all CI systems, and can be used locally if
    you run `cibuildwheel --platform linux`. This is preferred, but environment
    variables are better if you need to change per-matrix element
    (`CIBW_BUILD` is often in this category, for example), or if you cannot or do
    not want to change a `pyproject.toml` file. You can specify a different file to
    use with `--config-file` on the command line, as well.

### Configuration overrides {: #overrides }

One feature specific to the configuration files is the ability to override
settings based on selectors. To use, add a ``tool.cibuildwheel.overrides``
array, and specify a ``select`` string. Then any options you set will only
apply to items that match that selector. These are applied in order, with later
matches overriding earlier ones if multiple selectors match. Environment
variables always override static configuration.

A few of the options below have special handling in overrides. A different
`before-all` will trigger a new container to launch on Linux, and cannot be
overridden on macOS or Windows.  Overriding the image on linux will also
trigger new containers, one per image. Some commands are not supported;
`output-dir`, build/skip/test_skip selectors, and architectures cannot be
overridden.

##### Examples:

```toml
[tool.cibuildwheel.linux]
before-all = "yum install mylib"
test-command = "echo 'installed'"

[[tool.cibuildwheel.overrides]]
select = "*-musllinux*"
before-all = "apk add mylib"
```

This example will override the before-all command on musllinux only, but will
still run the test-command. Note the double brackets, this is an array in TOML,
which means it can be given multiple times.

```toml
[tool.cibuildwheel]
# Normal options, etc.
manylinux-x86_64-image = "manylinux2014"

[[tool.cibuildwheel.overrides]]
select = "cp36-*"
manylinux-x86_64-image = "manylinux1"

[[tool.cibuildwheel.overrides]]
select = "cp3{7,8,9}-*"
manylinux-x86_64-image = "manylinux2010"
```

This example will build CPython 3.6 wheels on manylinux1, CPython 3.7-3.9
wheels on manylinux2010, and manylinux2014 wheels for any newer Python
(like 3.10).

## Options summary

## Build selection

### `CIBW_PLATFORM` {: #platform}

> Override the auto-detected target platform

Options: `auto` `linux` `macos` `windows`

Default: `auto`

`auto` will auto-detect platform using environment variables, such as `TRAVIS_OS_NAME`/`APPVEYOR`/`CIRCLECI`.

- For `linux`, you need [Docker or Podman](#container-engine) running, on Linux, macOS, or Windows.
- For `macos` and `windows`, you need to be running on the respective system, with a working compiler toolchain installed - Xcode Command Line tools for macOS, and MSVC for Windows.

This option can also be set using the [command-line option](#command-line) `--platform`. This option is not available in the `pyproject.toml` config.

!!! tip
    You can use this option to locally debug your cibuildwheel config, instead of pushing to CI to test every change. For example:

    ```bash
    export CIBW_BUILD='cp37-*'
    export CIBW_TEST_COMMAND='pytest {package}/tests'
    cibuildwheel --platform linux .
    ```

    This is even more convenient if you store your cibuildwheel config in [`pyproject.toml`](#configuration-file).

    You can also run a single identifier with `--only <identifier>`. This will
    not require `--platform` or `--arch`, and will override any build/skip
    configuration.

### `CIBW_BUILD`, `CIBW_SKIP` {: #build-skip}

> Choose the Python versions to build

List of builds to build and skip. Each build has an identifier like `cp38-manylinux_x86_64` or `cp37-macosx_x86_64` - you can list specific ones to build and cibuildwheel will only build those, and/or list ones to skip and cibuildwheel won't try to build them.

When both options are specified, both conditions are applied and only builds with a tag that matches `CIBW_BUILD` and does not match `CIBW_SKIP` will be built.

When setting the options, you can use shell-style globbing syntax, as per [fnmatch](https://docs.python.org/3/library/fnmatch.html) with the addition of curly bracket syntax `{option1,option2}`, provided by [bracex](https://pypi.org/project/bracex/). All the build identifiers supported by cibuildwheel are shown below:

|               | macOS                                                                  | Windows                                             | Linux Intel                                                                                | Linux Other                                                                                |
|---------------|------------------------------------------------------------------------|-----------------------------------------------------|-----------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Python 3.6    | cp36-macosx_x86_64                                                     | cp36-win_amd64
cp36-win32                       | cp36-manylinux_x86_64
cp36-manylinux_i686
cp36-musllinux_x86_64
cp36-musllinux_i686     | cp36-manylinux_aarch64
cp36-manylinux_ppc64le
cp36-manylinux_s390x
cp36-musllinux_aarch64
cp36-musllinux_ppc64le
cp36-musllinux_s390x       |
| Python 3.7    | cp37-macosx_x86_64                                                     | cp37-win_amd64
cp37-win32                       | cp37-manylinux_x86_64
cp37-manylinux_i686
cp37-musllinux_x86_64
cp37-musllinux_i686     | cp37-manylinux_aarch64
cp37-manylinux_ppc64le
cp37-manylinux_s390x
cp37-musllinux_aarch64
cp37-musllinux_ppc64le
cp37-musllinux_s390x       |
| Python 3.8    | cp38-macosx_x86_64
cp38-macosx_universal2
cp38-macosx_arm64    | cp38-win_amd64
cp38-win32                       | cp38-manylinux_x86_64
cp38-manylinux_i686
cp38-musllinux_x86_64
cp38-musllinux_i686     | cp38-manylinux_aarch64
cp38-manylinux_ppc64le
cp38-manylinux_s390x
cp38-musllinux_aarch64
cp38-musllinux_ppc64le
cp38-musllinux_s390x       |
| Python 3.9    | cp39-macosx_x86_64
cp39-macosx_universal2
cp39-macosx_arm64    | cp39-win_amd64
cp39-win32
cp39-win_arm64    | cp39-manylinux_x86_64
cp39-manylinux_i686
cp39-musllinux_x86_64
cp39-musllinux_i686     | cp39-manylinux_aarch64
cp39-manylinux_ppc64le
cp39-manylinux_s390x
cp39-musllinux_aarch64
cp39-musllinux_ppc64le
cp39-musllinux_s390x       |
| Python 3.10   | cp310-macosx_x86_64
cp310-macosx_universal2
cp310-macosx_arm64 | cp310-win_amd64
cp310-win32
cp310-win_arm64 | cp310-manylinux_x86_64
cp310-manylinux_i686
cp310-musllinux_x86_64
cp310-musllinux_i686 | cp310-manylinux_aarch64
cp310-manylinux_ppc64le
cp310-manylinux_s390x
cp310-musllinux_aarch64
cp310-musllinux_ppc64le
cp310-musllinux_s390x |
| Python 3.11   | cp311-macosx_x86_64
cp311-macosx_universal2
cp311-macosx_arm64 | cp311-win_amd64
cp311-win32
cp311-win_arm64 | cp311-manylinux_x86_64
cp311-manylinux_i686
cp311-musllinux_x86_64
cp311-musllinux_i686 | cp311-manylinux_aarch64
cp311-manylinux_ppc64le
cp311-manylinux_s390x
cp311-musllinux_aarch64
cp311-musllinux_ppc64le
cp311-musllinux_s390x |
| Python 3.12   | cp312-macosx_x86_64
cp312-macosx_universal2
cp312-macosx_arm64 | cp312-win_amd64
cp312-win32
cp312-win_arm64 | cp312-manylinux_x86_64
cp312-manylinux_i686
cp312-musllinux_x86_64
cp312-musllinux_i686 | cp312-manylinux_aarch64
cp312-manylinux_ppc64le
cp312-manylinux_s390x
cp312-musllinux_aarch64
cp312-musllinux_ppc64le
cp312-musllinux_s390x |
| PyPy3.7 v7.3  | pp37-macosx_x86_64                                                     | pp37-win_amd64                                      | pp37-manylinux_x86_64
pp37-manylinux_i686                                                       | pp37-manylinux_aarch64                                                                                |
| PyPy3.8 v7.3  | pp38-macosx_x86_64
pp38-macosx_arm64                               | pp38-win_amd64                                      | pp38-manylinux_x86_64
pp38-manylinux_i686                                                       | pp38-manylinux_aarch64                                                                                |
| PyPy3.9 v7.3  | pp39-macosx_x86_64
pp39-macosx_arm64                               | pp39-win_amd64                                      | pp39-manylinux_x86_64
pp39-manylinux_i686                                                       | pp39-manylinux_aarch64                                                                                |
| PyPy3.10 v7.3 | pp310-macosx_x86_64
pp310-macosx_arm64                             | pp310-win_amd64                                     | pp310-manylinux_x86_64
pp310-manylinux_i686                                                     | pp310-manylinux_aarch64                                                                                |

The list of supported and currently selected build identifiers can also be retrieved by passing the `--print-build-identifiers` flag to cibuildwheel.
The format is `python_tag-platform_tag`, with tags similar to those in [PEP 425](https://www.python.org/dev/peps/pep-0425/#details).

For CPython, the minimally supported macOS version is 10.9; for PyPy 3.7, macOS 10.13 or higher is required.

Windows arm64 platform support is experimental.

See the [cibuildwheel 1 documentation](https://cibuildwheel.readthedocs.io/en/1.x/) for past end-of-life versions of Python, and PyPy2.7.

#### Examples

!!! tab examples "Environment variables"

    ```yaml
    # Only build on CPython 3.6
    CIBW_BUILD: cp36-*

    # Skip building on CPython 3.6 on the Mac
    CIBW_SKIP: cp36-macosx_x86_64

    # Skip building on CPython 3.8 on the Mac
    CIBW_SKIP: cp38-macosx_x86_64

    # Skip building on CPython 3.6 on all platforms
    CIBW_SKIP: cp36-*

    # Skip CPython 3.6 on Windows
    CIBW_SKIP: cp36-win*

    # Skip CPython 3.6 on 32-bit Windows
    CIBW_SKIP: cp36-win32

    # Skip CPython 3.6 and CPython 3.7
    CIBW_SKIP: cp36-* cp37-*

    # Skip Python 3.6 on Linux
    CIBW_SKIP: cp36-manylinux*

    # Skip 32-bit builds
    CIBW_SKIP: "*-win32 *-manylinux_i686"

    # Disable building PyPy wheels on all platforms
    CIBW_SKIP: pp*
    ```

    Separate multiple selectors with a space.

!!! tab examples "pyproject.toml"

    ```toml
    [tool.cibuildwheel]
    # Only build on CPython 3.6
    build = "cp36-*"

    # Skip building on CPython 3.6 on the Mac
    skip = "cp36-macosx_x86_64"

    # Skip building on CPython 3.8 on the Mac
    skip = "cp38-macosx_x86_64"

    # Skip building on CPython 3.6 on all platforms
    skip = "cp36-*"

    # Skip CPython 3.6 on Windows
    skip = "cp36-win*"

    # Skip CPython 3.6 on 32-bit Windows
    skip = "cp36-win32"

    # Skip CPython 3.6 and CPython 3.7
    skip = ["cp36-*", "cp37-*"]

    # Skip Python 3.6 on Linux
    skip = "cp36-manylinux*"

    # Skip 32-bit builds
    skip = ["*-win32", "*-manylinux_i686"]

    # Disable building PyPy wheels on all platforms
    skip = "pp*"
    ```

    It is generally recommended to set `CIBW_BUILD` as an environment variable, though `skip`
    tends to be useful in a config file; you can statically declare that you don't
    support PyPy, for example.

### `CIBW_ARCHS` {: #archs}
> Change the architectures built on your machine by default.

A list of architectures to build.

On macOS, this option can be used to cross-compile between `x86_64`,
`universal2` and `arm64` for Apple Silicon support.

On Linux, this option can be used to build non-native architectures under
emulation. See [this guide](faq.md#emulation) for more information.

On Windows, this option can be used to compile for `ARM64` from an Intel
machine, provided the cross-compiling tools are installed.

Options:

- Linux: `x86_64` `i686` `aarch64` `ppc64le` `s390x`
- macOS: `x86_64` `arm64` `universal2`
- Windows: `AMD64` `x86` `ARM64`
- `auto`: The default archs for your machine - see the table below.
    - `auto64`: Just the 64-bit auto archs
    - `auto32`: Just the 32-bit auto archs
- `native`: the native arch of the build machine - Matches [`platform.machine()`](https://docs.python.org/3/library/platform.html#platform.machine).
- `all` : expands to all the architectures supported on this OS. You may want
  to use [CIBW_BUILD](#build-skip) with this option to target specific
  architectures via build selectors.

Default: `auto`

| Runner | `native` | `auto` | `auto64` | `auto32` |
|---|---|---|---|---|
| Linux / Intel | `x86_64` | `x86_64` `i686` | `x86_64` | `i686` |
| Windows / Intel | `AMD64` | `AMD64` `x86` | `AMD64` | `x86` |
| Windows / ARM64 | `ARM64` | `ARM64` | `ARM64` | |
| macOS / Intel | `x86_64` | `x86_64` | `x86_64` |  |
| macOS / Apple Silicon | `arm64` | `arm64` | `arm64` |  |

If not listed above, `auto` is the same as `native`.

[setup-qemu-action]: https://github.com/docker/setup-qemu-action
[binfmt]: https://hub.docker.com/r/tonistiigi/binfmt

Platform-specific environment variables are also available:

 `CIBW_ARCHS_MACOS` | `CIBW_ARCHS_WINDOWS` | `CIBW_ARCHS_LINUX`

This option can also be set using the [command-line option](#command-line)
`--archs`. This option cannot be set in an `overrides` section in `pyproject.toml`.

#### Examples

!!! tab examples "Environment variables"

    ```yaml
    # Build `universal2` and `arm64` wheels on an Intel runner.
    # Note that the `arm64` wheel and the `arm64` part of the `universal2`
    # wheel cannot be tested in this configuration.
    CIBW_ARCHS_MACOS: "x86_64 universal2 arm64"

    # On an Linux Intel runner with qemu installed, build Intel and ARM wheels
    CIBW_ARCHS_LINUX: "auto aarch64"
    ```

    Separate multiple archs with a space.

!!! tab examples "pyproject.toml"

    ```toml
    # Build `universal2` and `arm64` wheels on an Intel runner.
    # Note that the `arm64` wheel and the `arm64` part of the `universal2`
    # wheel cannot be tested in this configuration.
    [tool.cibuildwheel.macos]
    archs = ["x86_64", "universal2", "arm64"]

    # On an Linux Intel runner with qemu installed, build Intel and ARM wheels
    [tool.cibuildwheel.linux]
    archs = ["auto", "aarch64"]
    ```

    It is generally recommended to use the environment variable or
    command-line option for Linux, as selecting archs often depends
    on your specific runner having qemu installed.

###  `CIBW_PROJECT_REQUIRES_PYTHON` {: #requires-python}
> Manually set the Python compatibility of your project

By default, cibuildwheel reads your package's Python compatibility from
`pyproject.toml` following the [project metadata specification](https://packaging.python.org/en/latest/specifications/declaring-project-metadata/)
or from `setup.cfg`; finally it will try to inspect the AST of `setup.py` for a
simple keyword assignment in a top level function call. If you need to override
this behaviour for some reason, you can use this option.

When setting this option, the syntax is the same as `project.requires-python`,
using 'version specifiers' like `>=3.6`, according to
[PEP440](https://www.python.org/dev/peps/pep-0440/#version-specifiers).

Default: reads your package's Python compatibility from `pyproject.toml`
(`project.requires-python`) or `setup.cfg` (`options.python_requires`) or
`setup.py` `setup(python_requires="...")`. If not found, cibuildwheel assumes
the package is compatible with all versions of Python that it can build.

!!! note
    Rather than using this environment variable, it's recommended you set this value
    statically in a way that your build backend can use it, too. This ensures
    that your package's metadata is correct when published on PyPI. This
    cibuildwheel-specific option is provided as an override, and therefore is only
    available in environment variable form.

      - If you have a `pyproject.toml` containing a `[project]` table, you can
        specify `requires-python` there.

        ```toml
        [project]
        ...
        requires-python = ">=3.6"
        ```

        Note that not all build backends fully support using a `[project]` table yet;
        specifically setuptools just added experimental support in version 61.
        Adding `[project]` to `pyproject.toml` requires all the other supported
        values to be specified there, or to be listed in `dynamic`.

      - If you're using setuptools, [you can set this value in `setup.cfg` (preferred) or `setup.py`](https://setuptools.pypa.io/en/latest/userguide/dependency_management.html#python-requirement)
        and cibuildwheel will read it from there.

#### Examples

!!! tab examples "Environment variables"

    ```yaml
    CIBW_PROJECT_REQUIRES_PYTHON: ">=3.6"
    ```

###  `CIBW_PRERELEASE_PYTHONS` {: #prerelease-pythons}
> Enable building with pre-release versions of Python if available

During the beta period, when new versions of Python are being tested,
cibuildwheel will often gain early support for beta releases. If you would
like to test wheel building with these versions, you can enable this flag.

!!! caution
    This option is provided for testing purposes only. It is not
    recommended to distribute wheels built when `CIBW_PRERELEASE_PYTHONS` is
    set, such as uploading to PyPI.  Please _do not_ upload these wheels to
    PyPI, as they are not guaranteed to work with the final Python release.
    Once Python is ABI stable and enters the release candidate phase, that
    version of Python will become available without this flag.

Default: Off (0) if Python is available in beta phase. No effect otherwise.

This option can also be set using the [command-line option](#command-line) `--prerelease-pythons`. This option is not available in the `pyproject.toml` config.

#### Examples

!!! tab examples "Environment variables"

    ```yaml
    # Include latest Python beta
    CIBW_PRERELEASE_PYTHONS: True
    ```

## Build customization

### `CIBW_BUILD_FRONTEND` {: #build-frontend}
> Set the tool to use to build, either "pip" (default for now) or "build"

Choose which build backend to use. Can either be "pip", which will run
`python -m pip wheel`, or "build", which will run `python -m build --wheel`.

!!! tip
    Until v2.0.0, [pip] was the only way to build wheels, and is still the
    default. However, we expect that at some point in the future, cibuildwheel
    will change the default to [build], in line with the PyPA's recommendation.
    If you want to try `build` before this, you can use this option.

[pip]: https://pip.pypa.io/en/stable/cli/pip_wheel/
[build]: https://github.com/pypa/build/

#### Examples

!!! tab examples "Environment variables"

    ```yaml
    # Switch to using build
    CIBW_BUILD_FRONTEND: "build"

    # Ensure pip is used even if the default changes in the future
    CIBW_BUILD_FRONTEND: "pip"
    ```

!!! tab examples "pyproject.toml"

    ```toml
    [tool.cibuildwheel]
    # Switch to using build
    build-frontend = "build"

    # Ensure pip is used even if the default changes in the future
    build-frontend = "pip"
    ```

### `CIBW_CONFIG_SETTINGS` {: #config-settings}
> Specify config-settings for the build backend.

Specify config settings for the build backend. Each space separated
item will be passed via `--config-setting`. In TOML, you can specify
a table of items, including arrays.

!!! tip
    Currently, "build" supports arrays for options, but "pip" only supports
    single values.

Platform-specific environment variables also available:

`CIBW_CONFIG_SETTINGS_MACOS` | `CIBW_CONFIG_SETTINGS_WINDOWS` | `CIBW_CONFIG_SETTINGS_LINUX`

#### Examples

!!! tab examples "Environment variables"

    ```yaml
    CIBW_CONFIG_SETTINGS: "--build-option=--use-mypyc"
    ```

!!! tab examples "pyproject.toml"

    ```toml
    [tool.cibuildwheel.config-settings]
    --build-option = "--use-mypyc"
    ```

### `CIBW_ENVIRONMENT` {: #environment}
> Set environment variables needed during the build

A list of environment variables to set during the build. Bash syntax should be used, even on Windows.

You must set this variable to pass variables to Linux builds (since they execute in a container). It also works for the other platforms.

You can use `$PATH` syntax to insert other variables, or the `$(pwd)` syntax to insert the output of other shell commands.

To specify more than one environment variable, separate the assignments by spaces.

Platform-specific environment variables are also available:

`CIBW_ENVIRONMENT_MACOS` | `CIBW_ENVIRONMENT_WINDOWS` | `CIBW_ENVIRONMENT_LINUX`

#### Examples

!!! tab examples "Environment variables"

    ```yaml
    # Set some compiler flags
    CIBW_ENVIRONMENT: CFLAGS='-g -Wall' CXXFLAGS='-Wall'

    # Append a directory to the PATH variable (this is expanded in the build environment)
    CIBW_ENVIRONMENT: PATH=$PATH:/usr/local/bin

    # Prepend a directory containing spaces on Windows.
    CIBW_ENVIRONMENT_WINDOWS: >
      PATH="C:\\Program Files\\PostgreSQL\\13\\bin;$PATH"

    # Set BUILD_TIME to the output of the `date` command
    CIBW_ENVIRONMENT: BUILD_TIME="$(date)"

    # Supply options to `pip` to affect how it downloads dependencies
    CIBW_ENVIRONMENT: PIP_EXTRA_INDEX_URL=https://pypi.myorg.com/simple

    # Any pip command-line options can be set using the PIP_ prefix
    # https://pip.pypa.io/en/stable/topics/configuration/#environment-variables
    CIBW_ENVIRONMENT: PIP_GLOBAL_OPTION="build_ext -j4"

    # Set two flags on linux only
    CIBW_ENVIRONMENT_LINUX: BUILD_TIME="$(date)" SAMPLE_TEXT="sample text"
    ```

    Separate multiple values with a space.

!!! tab examples "pyproject.toml"

    ```toml
    [tool.cibuildwheel]
    # Set some compiler flags
    environment = "CFLAGS='-g -Wall' CXXFLAGS='-Wall'"

    # Set some compiler flags using a TOML table
    environment = { CFLAGS="-g -Wall", CXXFLAGS="-Wall" }

    # Append a directory to the PATH variable (this is expanded in the build environment)
    environment = { PATH="$PATH:/usr/local/bin" }

    # Prepend a directory containing spaces on Windows.
    [tool.cibuildwheel.windows]
    environment = { PATH='C:\\Program Files\\PostgreSQL\\13\\bin;$PATH' }

    # Set BUILD_TIME to the output of the `date` command
    environment = { BUILD_TIME="$(date)" }

    # Supply options to `pip` to affect how it downloads dependencies
    environment = { PIP_EXTRA_INDEX_URL="https://pypi.myorg.com/simple" }

    # Any pip command-line option can be set using the PIP_ prefix
    # https://pip.pypa.io/en/stable/topics/configuration/#environment-variables
    environment = { PIP_GLOBAL_OPTION="build_ext -j4" }

    # Set two flags on linux only
    [tool.cibuildwheel.linux]
    environment = { BUILD_TIME="$(date)", SAMPLE_TEXT="sample text" }

    # Alternate form with out-of-line table for setting a few values
    [tool.cibuildwheel.linux.environment]
    BUILD_TIME = "$(date)"
    SAMPLE_TEXT = "sample text"
    ```

    In configuration mode, you can use a [TOML][] table instead of a raw string as shown above.

!!! note
    cibuildwheel always defines the environment variable `CIBUILDWHEEL=1`. This can be useful for [building wheels with optional extensions](faq.md#building-packages-with-optional-c-extensions).

### `CIBW_ENVIRONMENT_PASS_LINUX` {: #environment-pass}
> Set environment variables on the host to pass-through to the container during the build.

A list of environment variables to pass into the linux container during the build. It has no effect on the other platforms, which can already access all environment variables directly.

To specify more than one environment variable, separate the variable names by spaces.

#### Examples

!!! tab examples "Environment passthrough"

    ```yaml
    # Export a variable
    CIBW_ENVIRONMENT_PASS_LINUX: CFLAGS

    # Set two flags variables
    CIBW_ENVIRONMENT_PASS_LINUX: BUILD_TIME SAMPLE_TEXT
    ```

    Separate multiple values with a space.

!!! tab examples "pyproject.toml"

    ```toml
    [tool.cibuildwheel.linux]

    # Export a variable
    environment-pass = ["CFLAGS"]

    # Set two flags variables
    environment-pass = ["BUILD_TIME", "SAMPLE_TEXT"]
    ```

    In configuration mode, you can use a [TOML][] list instead of a raw string as shown above.

### `CIBW_BEFORE_ALL` {: #before-all}
> Execute a shell command on the build system before any wheels are built.

Shell command that runs before any builds are run, to build or install parts that do not depend on the specific version of Python.

This option is very useful for the Linux build, where builds take place in isolated containers managed by cibuildwheel. This command will run inside the container before the wheel builds start. Note, if you're building both `x86_64` and `i686` wheels (the default), your build uses two different container images. In that case, this command will execute twice - once per build container.

The placeholder `{package}` can be used here; it will be replaced by the path to the package being built by cibuildwheel.

On Windows and macOS, the version of Python available inside `CIBW_BEFORE_ALL` is whatever is available on the host machine. On Linux, a modern Python version is available on PATH.

This option has special behavior in the overrides section in `pyproject.toml`.
On linux, overriding it triggers a new container launch. It cannot be overridden
on macOS and Windows.

Platform-specific environment variables also available:

`CIBW_BEFORE_ALL_MACOS` | `CIBW_BEFORE_ALL_WINDOWS` | `CIBW_BEFORE_ALL_LINUX`

!!! note

    This command is executed in a different Python environment from the builds themselves. So you can't `pip install` a Python dependency in CIBW_BEFORE_ALL and use it in the build. Instead, look at [`CIBW_BEFORE_BUILD`](#before-build), or, if your project uses pyproject.toml, the [build-system.requires](https://peps.python.org/pep-0518/#build-system-table) field.

#### Examples

!!! tab examples "Environment variables"

    ```yaml
    # Build third party library
    CIBW_BEFORE_ALL: make -C third_party_lib

    # Install system library
    CIBW_BEFORE_ALL_LINUX: yum install -y libffi-devel

    # Chain multiple commands using && and > in a YAML file, like:
    CIBW_BEFORE_ALL: >
      yum install bzip2 -y &&
      make third_party
    ```

    For multiline commands, see the last example. The character `>` means that
    whitespace is collapsed to a single line, and '&&' between each command
    ensures that errors are not ignored. [Further reading on multiline YAML
    here.](https://yaml-multiline.info).

!!! tab examples "pyproject.toml"

    ```toml
    # Build third party library
    [tool.cibuildwheel]
    before-all = "make -C third_party_lib"

    # Install system library
    [tool.cibuildwheel.linux]
    before-all = "yum install -y libffi-devel"

    # Run multiple commands using an array
    before-all = [
      "yum install bzip2 -y",
      "make third_party",
    ]
    ```

    In configuration files, you can use a TOML array, and each line will be run sequentially - joined with `&&`.

 So for
`manylinux_2_24` the `CIBW_BEFORE_ALL_LINUX` command must use `apt-get -y`
instead.

### `CIBW_BEFORE_BUILD` {: #before-build}
> Execute a shell command preparing each wheel's build

A shell command to run before building the wheel. This option allows you to run a command in **each** Python environment before the `pip wheel` command. This is useful if you need to set up some dependency so it's available during the build.

If dependencies are required to build your wheel (for example if you include a header from a Python module), instead of using this command, we recommend adding requirements to a `pyproject.toml` file's `build-system.requires` array instead. This is reproducible, and users who do not get your wheels (such as Alpine or ClearLinux users) will still benefit.

The active Python binary can be accessed using `python`, and pip with `pip`; cibuildwheel makes sure the right version of Python and pip will be executed. The placeholder `{package}` can be used here; it will be replaced by the path to the package being built by cibuildwheel.

The command is run in a shell, so you can write things like `cmd1 && cmd2`.

Platform-specific environment variables are also available:

 `CIBW_BEFORE_BUILD_MACOS` | `CIBW_BEFORE_BUILD_WINDOWS` | `CIBW_BEFORE_BUILD_LINUX`

#### Examples

!!! tab examples "Environment variables"

    ```yaml
    # Install something required for the build (you might want to use pyproject.toml instead)
    CIBW_BEFORE_BUILD: pip install pybind11

    # Chain commands using &&
    CIBW_BEFORE_BUILD_LINUX: python scripts/install-deps.py && make clean

    # Run a script that's inside your project
    CIBW_BEFORE_BUILD: bash scripts/prepare_for_build.sh

    # If cibuildwheel is called with a package_dir argument, it's available as {package}
    CIBW_BEFORE_BUILD: "{package}/script/prepare_for_build.sh"
    ```

!!! tab examples "pyproject.toml"

    ```toml
    [tool.cibuildwheel]

    # Install something required for the build
    # (you might want to use build-system.requires instead)
    before-build = "pip install pybind11"

    # Chain commands using && or make an array.
    before-build = "python scripts/install-deps.py && make clean"
    before-build = [
        "python scripts/install-deps.py",
        "make clean",
    ]

    # Run a script that's inside your project
    before-build = "bash scripts/prepare_for_build.sh"

    # If cibuildwheel is called with a package_dir argument, it's available as {package}
    before-build = "{package}/script/prepare_for_build.sh"
    ```

    In configuration mode, you can use a array, and the items will be joined with `&&`. In TOML, using a single-quote string will avoid escapes - useful for
    Windows paths.

!!! note
    If you need Python dependencies installed for the build, we recommend using
    `pyproject.toml`'s `build-system.requires` instead. This is an example
    `pyproject.toml` file:

        [build-system]
        requires = [
            "setuptools>=42",
            "wheel",
            "Cython",
            "numpy==1.13.3; python_version<'3.5'",
            "oldest-supported-numpy; python_version>='3.5'",
        ]

        build-backend = "setuptools.build_meta"

    This [PEP 517][]/[PEP 518][] style build allows you to completely control
    the build environment in cibuildwheel, [PyPA-build][], and pip, doesn't
    force downstream users to install anything they don't need, and lets you do
    more complex pinning (Cython, for example, requires a wheel to be built
    with an equal or earlier version of NumPy; pinning in this way is the only
    way to ensure your module works on all available NumPy versions).

    [PyPA-build]: https://pypa-build.readthedocs.io/en/latest/
    [PEP 517]: https://www.python.org/dev/peps/pep-0517/
    [PEP 518]: https://www.python.org/dev/peps/pep-0517/

### `CIBW_REPAIR_WHEEL_COMMAND` {: #repair-wheel-command}
> Execute a shell command to repair each built wheel

Default:

- on Linux: `'auditwheel repair -w {dest_dir} {wheel}'`
- on macOS: `'delocate-wheel --require-archs {delocate_archs} -w {dest_dir} -v {wheel}'`
- on Windows: `''`

A shell command to repair a built wheel by copying external library dependencies into the wheel tree and relinking them.
The command is run on each built wheel (except for pure Python ones) before testing it.

The following placeholders must be used inside the command and will be replaced by cibuildwheel:

- `{wheel}` for the absolute path to the built wheel
- `{dest_dir}` for the absolute path of the directory where to create the repaired wheel
- `{delocate_archs}` (macOS only) comma-separated list of architectures in the wheel.

The command is run in a shell, so you can run multiple commands like `cmd1 && cmd2`.

Platform-specific environment variables are also available:

`CIBW_REPAIR_WHEEL_COMMAND_MACOS` | `CIBW_REPAIR_WHEEL_COMMAND_WINDOWS` | `CIBW_REPAIR_WHEEL_COMMAND_LINUX`

!!! tip
    cibuildwheel doesn't yet ship a default repair command for Windows.

    **If that's an issue for you, check out [delvewheel]** - a new package that aims to do the same as auditwheel or delocate for Windows.

    Because delvewheel is still relatively early-stage, cibuildwheel does not yet run it by default. However, we'd recommend giving it a try! See the examples below for usage.

    [Delvewheel]: https://github.com/adang1345/delvewheel

#### Examples

!!! tab examples "Environment variables"

    ```yaml
    # Use delvewheel on windows
    CIBW_BEFORE_BUILD_WINDOWS: "pip install delvewheel"
    CIBW_REPAIR_WHEEL_COMMAND_WINDOWS: "delvewheel repair -w {dest_dir} {wheel}"

    # Don't repair macOS wheels
    CIBW_REPAIR_WHEEL_COMMAND_MACOS: ""

    # Pass the `--lib-sdir .` flag to auditwheel on Linux
    CIBW_REPAIR_WHEEL_COMMAND_LINUX: "auditwheel repair --lib-sdir . -w {dest_dir} {wheel}"

    # Multi-line example - use && to join on all platforms
    CIBW_REPAIR_WHEEL_COMMAND: >
      python scripts/repair_wheel.py -w {dest_dir} {wheel} &&
      python scripts/check_repaired_wheel.py -w {dest_dir} {wheel}
    ```

    ```yaml
    # Use abi3audit to catch issues with Limited API wheels
    CIBW_REPAIR_WHEEL_COMMAND_LINUX: >
      auditwheel repair -w {dest_dir} {wheel} &&
      pipx run abi3audit --strict --report {wheel}
    CIBW_REPAIR_WHEEL_COMMAND_MACOS: >
      delocate-wheel --require-archs {delocate_archs} -w {dest_dir} -v {wheel} &&
      pipx run abi3audit --strict --report {wheel}
    CIBW_REPAIR_WHEEL_COMMAND_WINDOWS: >
      pipx run abi3audit --strict --report {wheel}
    ```

!!! tab examples "pyproject.toml"

    ```toml
    # Use delvewheel on windows
    [tool.cibuildwheel.windows]
    before-build = "pip install delvewheel"
    repair-wheel-command = "delvewheel repair -w {dest_dir} {wheel}"

    # Don't repair macOS wheels
    [tool.cibuildwheel.macos]
    repair-wheel-command = ""

    # Pass the `--lib-sdir .` flag to auditwheel on Linux
    [tool.cibuildwheel.linux]
    repair-wheel-command = "auditwheel repair --lib-sdir . -w {dest_dir} {wheel}"

    # Multi-line example
    [tool.cibuildwheel]
    repair-wheel-command = [
      'python scripts/repair_wheel.py -w {dest_dir} {wheel}',
      'python scripts/check_repaired_wheel.py -w {dest_dir} {wheel}',
    ]
    ```

    ```toml
    # Use abi3audit to catch issues with Limited API wheels
    [tool.cibuildwheel.linux]
    repair-wheel-command = [
      "auditwheel repair -w {dest_dir} {wheel}",
      "pipx run abi3audit --strict --report {wheel}",
    ]
    [tool.cibuildwheel.macos]
    repair-wheel-command = [
      "delocate-wheel --require-archs {delocate_archs} -w {dest_dir} -v {wheel}",
      "pipx run abi3audit --strict --report {wheel}",
    ]
    [tool.cibuildwheel.windows]
    repair-wheel-command = "pipx run abi3audit --strict --report {wheel}"
    ```

    In configuration mode, you can use an inline array, and the items will be joined with `&&`.

### `CIBW_MANYLINUX_*_IMAGE`, `CIBW_MUSLLINUX_*_IMAGE` {: #linux-image}
> Specify alternative manylinux / musllinux container images

The available options are (default value):

- `CIBW_MANYLINUX_X86_64_IMAGE` ([`quay.io/pypa/manylinux2014_x86_64`](https://quay.io/pypa/manylinux2014_x86_64))
- `CIBW_MANYLINUX_I686_IMAGE` ([`quay.io/pypa/manylinux2014_i686`](https://quay.io/pypa/manylinux2014_i686))
- `CIBW_MANYLINUX_PYPY_X86_64_IMAGE` ([`quay.io/pypa/manylinux2014_x86_64`](https://quay.io/pypa/manylinux2014_x86_64))
- `CIBW_MANYLINUX_AARCH64_IMAGE` ([`quay.io/pypa/manylinux2014_aarch64`](https://quay.io/pypa/manylinux2014_aarch64))
- `CIBW_MANYLINUX_PPC64LE_IMAGE` ([`quay.io/pypa/manylinux2014_ppc64le`](https://quay.io/pypa/manylinux2014_ppc64le))
- `CIBW_MANYLINUX_S390X_IMAGE` ([`quay.io/pypa/manylinux2014_s390x`](https://quay.io/pypa/manylinux2014_s390x))
- `CIBW_MANYLINUX_PYPY_AARCH64_IMAGE` ([`quay.io/pypa/manylinux2014_aarch64`](https://quay.io/pypa/manylinux2014_aarch64))
- `CIBW_MANYLINUX_PYPY_I686_IMAGE` ([`quay.io/pypa/manylinux2014_i686`](https://quay.io/pypa/manylinux2014_i686))
- `CIBW_MUSLLINUX_X86_64_IMAGE` ([`quay.io/pypa/musllinux_1_1_x86_64`](https://quay.io/pypa/musllinux_1_1_x86_64))
- `CIBW_MUSLLINUX_I686_IMAGE` ([`quay.io/pypa/musllinux_1_1_i686`](https://quay.io/pypa/musllinux_1_1_i686))
- `CIBW_MUSLLINUX_AARCH64_IMAGE` ([`quay.io/pypa/musllinux_1_1_aarch64`](https://quay.io/pypa/musllinux_1_1_aarch64))
- `CIBW_MUSLLINUX_PPC64LE_IMAGE` ([`quay.io/pypa/musllinux_1_1_ppc64le`](https://quay.io/pypa/musllinux_1_1_ppc64le))
- `CIBW_MUSLLINUX_S390X_IMAGE` ([`quay.io/pypa/musllinux_1_1_s390x`](https://quay.io/pypa/musllinux_1_1_s390x))

Set an alternative Docker image to be used for building [manylinux / musllinux](https://github.com/pypa/manylinux) wheels.

For `CIBW_MANYLINUX_*_IMAGE`, the value of this option can either be set to `manylinux1`, `manylinux2010`, `manylinux2014`, `manylinux_2_24` or `manylinux_2_28` to use a pinned version of the [official manylinux images](https://github.com/pypa/manylinux). Alternatively, set these options to any other valid Docker image name. For PyPy, the `manylinux1` image is not available. For architectures other
than x86 (x86\_64 and i686) `manylinux2014`, `manylinux_2_24` or `manylinux_2_28` must be used, because the first version of the manylinux specification that supports additional architectures is `manylinux2014`. `manylinux_2_28` is not supported for `i686` architecture.

For `CIBW_MUSLLINUX_*_IMAGE`, the value of this option can either be set to `musllinux_1_1` or `musllinux_1_2` to use a pinned version of the [official musllinux images](https://github.com/pypa/musllinux). Alternatively, set these options to any other valid Docker image name.

If this option is blank, it will fall though to the next available definition (environment variable -> pyproject.toml -> default).

If setting a custom image, you'll need to make sure it can be used in the same way as the default images: all necessary Python and pip versions need to be present in `/opt/python/`, and the auditwheel tool needs to be present for cibuildwheel to work. Apart from that, the architecture and relevant shared system libraries need to be compatible to the relevant standard to produce valid manylinux1/manylinux2010/manylinux2014/manylinux_2_24/manylinux_2_28/musllinux_1_1 wheels (see [pypa/manylinux on GitHub](https://github.com/pypa/manylinux), [PEP 513](https://www.python.org/dev/peps/pep-0513/), [PEP 571](https://www.python.org/dev/peps/pep-0571/), [PEP 599](https://www.python.org/dev/peps/pep-0599/), [PEP 600](https://www.python.org/dev/peps/pep-0600/) and [PEP 656](https://www.python.org/dev/peps/pep-0656/) for more details).

Auditwheel detects the version of the manylinux / musllinux standard in the image through the `AUDITWHEEL_PLAT` environment variable, as cibuildwheel has no way of detecting the correct `--plat` command line argument to pass to auditwheel for a custom image. If a custom image does not correctly set this `AUDITWHEEL_PLAT` environment variable, the `CIBW_ENVIRONMENT` option can be used to do so (e.g., `CIBW_ENVIRONMENT='AUDITWHEEL_PLAT="manylinux2010_$(uname -m)"'`).

#### Examples

!!! tab examples "Environment variables"

    ```yaml
    # Build using the manylinux1 image to ensure manylinux1 wheels are produced
    # Not setting PyPy to manylinux1, since there is no manylinux1 PyPy image.
    CIBW_MANYLINUX_X86_64_IMAGE: manylinux1
    CIBW_MANYLINUX_I686_IMAGE: manylinux1

    # Build using the manylinux2014 image
    CIBW_MANYLINUX_X86_64_IMAGE: manylinux2014
    CIBW_MANYLINUX_I686_IMAGE: manylinux2014
    CIBW_MANYLINUX_PYPY_X86_64_IMAGE: manylinux2014
    CIBW_MANYLINUX_PYPY_I686_IMAGE: manylinux2014

    # Build using the latest manylinux2014 release, instead of the cibuildwheel
    # pinned version
    CIBW_MANYLINUX_X86_64_IMAGE: quay.io/pypa/manylinux2014_x86_64:latest
    CIBW_MANYLINUX_I686_IMAGE: quay.io/pypa/manylinux2014_i686:latest
    CIBW_MANYLINUX_PYPY_X86_64_IMAGE: quay.io/pypa/manylinux2014_x86_64:latest
    CIBW_MANYLINUX_PYPY_I686_IMAGE: quay.io/pypa/manylinux2014_i686:latest

    # Build using a different image from the docker registry
    CIBW_MANYLINUX_X86_64_IMAGE: dockcross/manylinux-x64
    CIBW_MANYLINUX_I686_IMAGE: dockcross/manylinux-x86
    ```

!!! tab examples "pyproject.toml"

    ```toml
    [tool.cibuildwheel]
    # Build using the manylinux1 image to ensure manylinux1 wheels are produced
    # Not setting PyPy to manylinux1, since there is no manylinux1 PyPy image.
    manylinux-x86_64-image = "manylinux1"
    manylinux-i686-image = "manylinux1"

    # Build using the manylinux2014 image
    manylinux-x86_64-image = "manylinux2014"
    manylinux-i686-image = "manylinux2014"
    manylinux-pypy_x86_64-image = "manylinux2014"
    manylinux-pypy_i686-image = "manylinux2014"

    # Build using the latest manylinux2010 release, instead of the cibuildwheel
    # pinned version
    manylinux-x86_64-image = "quay.io/pypa/manylinux2010_x86_64:latest"
    manylinux-i686-image = "quay.io/pypa/manylinux2010_i686:latest"
    manylinux-pypy_x86_64-image = "quay.io/pypa/manylinux2010_x86_64:latest"
    manylinux-pypy_i686-image = "quay.io/pypa/manylinux2010_i686:latest"

    # Build using a different image from the docker registry
    manylinux-x86_64-image = "dockcross/manylinux-x64"
    manylinux-i686-image = "dockcross/manylinux-x86"
    ```

    Like any other option, these can be placed in `[tool.cibuildwheel.linux]`
    if you prefer; they have no effect on `macos` and `windows`.

### `CIBW_CONTAINER_ENGINE` {: #container-engine}
> Specify the container engine to use when building Linux wheels

Options:

- `docker[;create_args: ...]`
- `podman[;create_args: ...]`

Default: `docker`

Set the container engine to use. Docker is the default, or you can switch to
[Podman](https://podman.io/). To use Docker, you need to have a Docker daemon
running and `docker` available on PATH. To use Podman, it needs to be
installed and `podman` available on PATH.

Arguments can be supplied to the container engine. Currently, the only option
that's customisable is 'create_args'. Parameters to create_args are
space-separated strings, which are passed to the container engine on the
command line when it's creating the container. If you want to include spaces
inside a parameter, use shell-style quoting.

!!! tip

    While most users will stick with Docker, Podman is available in different
    contexts - for example, it can be run inside a Docker container, or without
    root access. Thanks to the [OCI], images are compatible between engines, so
    you can still use the regular manylinux/musllinux containers.

[OCI]: https://opencontainers.org/

#### Examples

!!! tab examples "Environment variables"

    ```yaml
    # use podman instead of docker
    CIBW_CONTAINER_ENGINE: podman

    # pass command line options to 'docker create'
    CIBW_CONTAINER_ENGINE: "docker; create_args: --gpus all"
    ```

!!! tab examples "pyproject.toml"

    ```toml
    [tool.cibuildwheel]
    # use podman instead of docker
    container-engine = "podman"

    # pass command line options to 'docker create'
    container-engine = { name = "docker", create-args = ["--gpus", "all"]}
    ```

### `CIBW_DEPENDENCY_VERSIONS` {: #dependency-versions}
> Specify how cibuildwheel controls the versions of the tools it uses

Options: `pinned` `latest` `<your constraints file>`

Default: `pinned`

If `CIBW_DEPENDENCY_VERSIONS` is `pinned`, cibuildwheel uses versions of tools
like `pip`, `setuptools`, `virtualenv` that were pinned with that release of
cibuildwheel. This represents a known-good set of dependencies, and is
recommended for build repeatability.

If set to `latest`, cibuildwheel will use the latest of these packages that
are available on PyPI. This might be preferable if these packages have bug
fixes that can't wait for a new cibuildwheel release.

To control the versions of dependencies yourself, you can supply a [pip
constraints](https://pip.pypa.io/en/stable/user_guide/#constraints-files) file
here and it will be used instead.

!!! note
    If you need different dependencies for each python version, provide them
    in the same folder with a `-pythonXY` suffix. e.g. if your
    `CIBW_DEPENDENCY_VERSIONS=./constraints.txt`, cibuildwheel will use
    `./constraints-python37.txt` on Python 3.7, or fallback to
    `./constraints.txt` if that's not found.

Platform-specific environment variables are also available:

`CIBW_DEPENDENCY_VERSIONS_MACOS` | `CIBW_DEPENDENCY_VERSIONS_WINDOWS`

!!! note
    This option does not affect the tools used on the Linux build - those versions
    are bundled with the manylinux/musllinux image that cibuildwheel uses. To change
    dependency versions on Linux, use the [CIBW_MANYLINUX_* / CIBW_MUSLLINUX_*](#linux-image)
    options.

#### Examples

!!! tab examples "Environment variables"

    ```yaml
    # Use tools versions that are bundled with cibuildwheel (this is the default)
    CIBW_DEPENDENCY_VERSIONS: pinned

    # Use the latest versions available on PyPI
    CIBW_DEPENDENCY_VERSIONS: latest

    # Use your own pip constraints file
    CIBW_DEPENDENCY_VERSIONS: ./constraints.txt
    ```

!!! tab examples "pyproject.toml"

    ```toml
    [tool.cibuildwheel]
    # Use tools versions that are bundled with cibuildwheel (this is the default)
    dependency-versions = "pinned"

    # Use the latest versions available on PyPI
    dependency-versions = "latest"

    # Use your own pip constraints file
    dependency-versions = "./constraints.txt"
    ```

## Testing

### `CIBW_TEST_COMMAND` {: #test-command}
> Execute a shell command to test each built wheel

Shell command to run tests after the build. The wheel will be installed
automatically and available for import from the tests. To ensure the wheel is
imported by your tests (instead of your source copy), **tests are not run from
your project directory**. Use the placeholders `{project}` and `{package}` when
specifying paths in your project. If this variable is not set, your wheel will
not be installed after building.

- `{project}` is an absolute path to the project root - the working directory
  where cibuildwheel was called.
- `{package}` is the path to the package being built - the `package_dir`
  argument supplied to cibuildwheel on the command line.

The command is run in a shell, so you can write things like `cmd1 && cmd2`.

Platform-specific environment variables are also available:

`CIBW_TEST_COMMAND_MACOS` | `CIBW_TEST_COMMAND_WINDOWS` | `CIBW_TEST_COMMAND_LINUX`

#### Examples

!!! tab examples "Environment variables"

    ```yaml
    # Run the project tests against the installed wheel using `nose`
    CIBW_TEST_COMMAND: nosetests {project}/tests

    # Run the package tests using `pytest`
    CIBW_TEST_COMMAND: pytest {package}/tests

    # Trigger an install of the package, but run nothing of note
    CIBW_TEST_COMMAND: "echo Wheel installed"

    # Multi-line example - join with && on all platforms
    CIBW_TEST_COMMAND: >
      pytest {package}/tests &&
      python {package}/test.py
    ```

!!! tab examples "pyproject.toml"

    ```toml
    [tool.cibuildwheel]
    # Run the project tests against the installed wheel using `nose`
    test-command = "nosetests {project}/tests"

    # Run the package tests using `pytest`
    test-command = "pytest {package}/tests"

    # Trigger an install of the package, but run nothing of note
    test-command = "echo Wheel installed"

    # Multiline example
    test-command = [
      "pytest {package}/tests",
      "python {package}/test.py",
    ]
    ```

    In configuration files, you can use an array, and the items will be joined with `&&`.

!!! note

    It isn't recommended to `cd` to your project directory before running tests,
    because Python might resolve `import yourpackage` relative to the working dir,
    and we want to test the wheel you just built. However, if you're sure that's not
    an issue for you and your workflow requires it, on Windows you should do `cd /d`,
    because the CWD and project dir might be on different drives.

### `CIBW_BEFORE_TEST` {: #before-test}
> Execute a shell command before testing each wheel

A shell command to run in **each** test virtual environment, before your wheel is installed and tested. This is useful if you need to install a non-pip package, invoke pip with different environment variables,
or perform a multi-step pip installation (e.g. installing scikit-build or Cython before installing test package).

The active Python binary can be accessed using `python`, and pip with `pip`; cibuildwheel makes sure the right version of Python and pip will be executed. The placeholder `{package}` can be used here; it will be replaced by the path to the package being built by cibuildwheel.

The command is run in a shell, so you can write things like `cmd1 && cmd2`.

Platform-specific environment variables are also available:

 `CIBW_BEFORE_TEST_MACOS` | `CIBW_BEFORE_TEST_WINDOWS` | `CIBW_BEFORE_TEST_LINUX`

#### Examples

!!! tab examples "Environment variables"

    ```yaml
    # Install test dependencies with overwritten environment variables.
    CIBW_BEFORE_TEST: CC=gcc CXX=g++ pip install -r requirements.txt

    # Chain commands using &&
    CIBW_BEFORE_TEST: rm -rf ./data/cache && mkdir -p ./data/cache

    # Install non pip python package
    CIBW_BEFORE_TEST: >
      cd some_dir &&
      ./configure &&
      make &&
      make install

    # Install python packages that are required to install test dependencies
    CIBW_BEFORE_TEST: pip install cmake scikit-build
    ```

!!! tab examples "pyproject.toml"

    ```toml
    [tool.cibuildwheel]
    # Install test dependencies with overwritten environment variables.
    before-test = "CC=gcc CXX=g++ pip install -r requirements.txt"

    # Chain commands using && or using an array
    before-test = "rm -rf ./data/cache && mkdir -p ./data/cache"
    before-test = [
        "rm -rf ./data/cache",
        "mkdir -p ./data/cache",
    ]

    # Install non pip python package
    before-test = [
        "cd some_dir",
        "./configure",
        "make",
        "make install",
    ]

    # Install python packages that are required to install test dependencies
    [tool.cibuildwheel]
    before-test = "pip install cmake scikit-build"
    ```

    In configuration files, you can use an array, and the items will be joined with `&&`.

### `CIBW_TEST_REQUIRES` {: #test-requires}
> Install Python dependencies before running the tests

Space-separated list of dependencies required for running the tests.

Platform-specific environment variables are also available:

`CIBW_TEST_REQUIRES_MACOS` | `CIBW_TEST_REQUIRES_WINDOWS` | `CIBW_TEST_REQUIRES_LINUX`

#### Examples

!!! tab examples "Environment variables"

    ```yaml
    # Install pytest before running CIBW_TEST_COMMAND
    CIBW_TEST_REQUIRES: pytest

    # Install specific versions of test dependencies
    CIBW_TEST_REQUIRES: nose==1.3.7 moto==0.4.31
    ```

!!! tab examples "pyproject.toml"

    ```toml
    # Install pytest before running CIBW_TEST_COMMAND
    [tool.cibuildwheel]
    test-requires = "pytest"

    # Install specific versions of test dependencies
    [tool.cibuildwheel]
    test-requires = ["nose==1.3.7", "moto==0.4.31"]
    ```

    In configuration files, you can use an array, and the items will be joined with a space.

### `CIBW_TEST_EXTRAS` {: #test-extras}
> Install your wheel for testing using `extras_require`

List of
[extras_require](https://setuptools.readthedocs.io/en/latest/setuptools.html#declaring-extras-optional-features-with-their-own-dependencies)
options that should be included when installing the wheel prior to running the
tests. This can be used to avoid having to redefine test dependencies in
`CIBW_TEST_REQUIRES` if they are already defined in `setup.py` or
`setup.cfg`.

Platform-specific environment variables are also available:

`CIBW_TEST_EXTRAS_MACOS` | `CIBW_TEST_EXTRAS_WINDOWS` | `CIBW_TEST_EXTRAS_LINUX`

#### Examples

!!! tab examples "Environment variables"

    ```yaml
    # Will cause the wheel to be installed with `pip install <wheel_file>[test,qt]`
    CIBW_TEST_EXTRAS: "test,qt"
    ```

    Separate multiple items with a comma.

!!! tab examples "pyproject.toml"

    ```toml
    [tool.cibuildwheel]
    # Will cause the wheel to be installed with `pip install <wheel_file>[test,qt]`
    test-extras = ["test", "qt"]
    ```

    In configuration files, you can use an inline array, and the items will be joined with a comma.

### `CIBW_TEST_SKIP` {: #test-skip}
> Skip running tests on some builds

This will skip testing on any identifiers that match the given skip patterns (see [`CIBW_SKIP`](#build-skip)). This can be used to mask out tests for wheels that have missing dependencies upstream that are slow or hard to build, or to skip slow tests on emulated architectures.

With macOS `universal2` wheels, you can also skip the individual archs inside the wheel using an `:arch` suffix. For example, `cp39-macosx_universal2:x86_64` or `cp39-macosx_universal2:arm64`.

This option is not supported in the overrides section in `pyproject.toml`.

#### Examples

!!! tab examples "Environment variables"

    ```yaml
    # Will avoid testing on emulated architectures
    CIBW_TEST_SKIP: "*-*linux_{aarch64,ppc64le,s390x}"

    # Skip trying to test arm64 builds on Intel Macs
    CIBW_TEST_SKIP: "*-macosx_arm64 *-macosx_universal2:arm64"
    ```

!!! tab examples "pyproject.toml"

    ```toml
    [tool.cibuildwheel]
    # Will avoid testing on emulated architectures
    test-skip = "*-*linux_{aarch64,ppc64le,s390x}"

    # Skip trying to test arm64 builds on Intel Macs
    test-skip = "*-macosx_arm64 *-macosx_universal2:arm64"
    ```

## Other

### `CIBW_BUILD_VERBOSITY` {: #build-verbosity}
> Increase/decrease the output of pip wheel

A number from 1 to 3 to increase the level of verbosity (corresponding to invoking pip with `-v`, `-vv`, and `-vvv`), between -1 and -3 (`-q`, `-qq`, and `-qqq`), or just 0 (default verbosity). These flags are useful while debugging a build when the output of the actual build invoked by `pip wheel` is required. Has no effect on the `build` backend, which produces verbose output by default.

Platform-specific environment variables are also available:

`CIBW_BUILD_VERBOSITY_MACOS` | `CIBW_BUILD_VERBOSITY_WINDOWS` | `CIBW_BUILD_VERBOSITY_LINUX`

#### Examples

!!! tab examples "Environment variables"

    ```yaml
    # Increase pip debugging output
    CIBW_BUILD_VERBOSITY: 1
    ```

!!! tab examples "pyproject.toml"

    ```toml
    [tool.cibuildwheel]
    # Increase pip debugging output
    build-verbosity = 1
    ```

## Command line options {: #command-line}

```text
« subprocess_run("cibuildwheel", "--help") »
```

## Placeholders

Some options support placeholders, like `{project}`, `{package}` or `{wheel}`, that are substituted by cibuildwheel before they are used. If, for some reason, you need to write the literal name of a placeholder, e.g. literally `{project}` in a command that would ordinarily substitute `{project}`, prefix it with a hash character - `#{project}`. This is only necessary in commands where the specific string between the curly brackets would be substituted - otherwise, strings not modified.

[TOML]: https://toml.io

repository: pypa/cibuildwheel

branch_name: refs/heads/main

gha_language: Python

gha_license_id: NOASSERTION

repo_name: pypa/cibuildwheel


text:
# UIImage+MQMetal

```swift
.mtlTexture2D(device: MTLDevice) -> MTLTexture?
```

获取`RegionMake2D`的`MTLTexture`

repository: M-Quadra/MQKit

repo_name: M-Quadra/MQKit


text:
# MetaCloud for Resource Provisioning
Multi-Objective Optimization for Dynamic Resource Provisioning in a Multi-Cloud Environment using Lion Optimization Algorithm

This project is based on cloudsim.

IEEE link: https://ieeexplore.ieee.org/document/9305822

IEEE DOI: https://doi.org/10.1109/CINTI51262.2020.9305822

Published in : https://ieeexplore.ieee.org/xpl/conhome/9305681/proceeding


text:
![logo][]
[Back To - Home][]

# Contributing - nScale Client

The nscale client is the command line interface for nscale. It is a fairly straightforward script which sends commmands to the kernel.

This guide is designed to help you get up and running with a development version of the nscale-client.

## Pre-Requisites
You should have a working vesrion of the kernel installed on your machine.

You could just use your globally installed kernel but __ideally__ you should have a [development kernel][dev-kernel] set up.

For the purposes of this guide, we will assume a development kernel is set up.

## Fork and Clone

Head over to the ![nscale-client][] repo and fork it.

clone your repo:

```bash
git clone git@github.com:your-username/nscale-client
```

cd into the folder and add the nearform repo as a remote in case there are updates you need to pull:

```bash
git remote add nearform git@github.com:nearform/nscale-client
```

install dependencies with `npm install`.

## Start the Client

The entry point for the nscale-client is the `nscale.js` script. This is what gets started when you normally run an `nscale` command.

```bash
./nscale.js
```

Will give you the help output.

The client is _useless_ on its own. We need to open up another terminal window and start the kernel.

if you have a `dev-kernel` symlink set up simply run:

```bash
dev-kernel -c ~/.nscale/config/config.json
```
otherwise cd to wherever you have your kernel located and run:

```bash
bin/nscale-kernel.js -c ~/.nscale/config/config.json
```
Once the kernel is running try issue a command from the client script:

```bash
./nscale.js login
```

You should see some logging output in the kernel terminal window.

## Pro Tip - Symbolic Link

If we have a `dev-kernel` link set up, why not set up one for our client?
Now we can have a full development version of nscale that we can start on the fly. No need for typing ridiculous paths or jumping from folder to folder.

To create the link, from the nscale-client directory run:

```bash
ln -s nscale.js /usr/local/bin/nclient
```

this creates a link called `nclient`. Choose whatever name you wish!

You are now ready to hack the nscale-client!

To chat with the owners/contributors visit the [nscale gitter][gitter] page.

If you make any improvements please check out our general guidelines for submitting a [pull request.][pull-requests]

[Back To - Home][]

[gitter]: https://gitter.im/nearform/nscale
[pull-requests]: ./pull-requests.md
[nscale-client]: https://github.com/nearform/nscale-client
[dev-kernel]: ./nscale-kernel.md
[Back To - Home]: ./README.md
[logo]: ../_imgs/logo.png


text:
# Noable TED Talks on Programming
### Best programming talks, seen on TED

_Videos are, currently, in no order._

* [A 12-year-old app developer | Thomas Suarez](https://www.youtube.com/watch?v=Fkd9TWUtFm0)  (4:40)

>Most 12-year-olds love playing videogames -- Thomas Suarez taught himself how to create them. After developing iPhone apps like "Bustin Jeiber," a whack-a-mole game, he is now using his skills to help other kids become developers. (Filmed at TEDxManhattanBeach.)

* [The mind behind Linux | Linus Torvalds](https://www.youtube.com/watch?v=o8NPllzkFhE) (21:30)

>In a rare interview with TED Curator Chris Anderson, Torvalds discusses with remarkable openness the personality traits that prompted his unique philosophy of work, engineering and life. "I am not a visionary, I'm an engineer," Torvalds says. "I'm perfectly happy with all the people who are walking around and just staring at the clouds ... but I'm looking at the ground, and I want to fix the pothole that's right in front of me before I fall in."

* [The magic ingredient that brings Pixar movies to life | Danielle Feinberg](https://www.youtube.com/watch?v=Z1R1z9ipFnM) (12:04)

>Danielle Feinberg, Pixar's director of photography, creates stories with soul and wonder using math, science and code. Go behind the scenes of Finding Nemo, Toy Story, Brave, WALL-E and more, and discover how Pixar interweaves art and science to create fantastic worlds where the things you imagine can become real. This talk comes from the PBS special "TED Talks: Science & Wonder."

# Contribuions
Contribuions are highly welcome. Just make sure :

* Obviously, the talk must be from a TED, or TEDx event.
* The content (talk) must be about programming, tools, libraries or relevant topics.
* Please follow the format about; please create a separate issue if you want to suggest about formatting.
* In one PR, please don't include multiple videos.
* Please maintain a respectful environment.

repository: kmonsoor/ted-programming-talks

repo_name: kmonsoor/ted-programming-talks


text:
# AlphaForce
AlphaForce is a deep reinforcement learning tool based on pytorch.
AlphaForce realizes modular design, which is simple and easy to use.

## Implemented Algorithms

### Policy Gradient (Vanilla)
### DQN
###

## Project Structure

## Citing

If you use `AlphaForce` in your research, you can cite it as follows:
```bibtex
@misc{AlphaForce2019,
    author = {Xuekun Zhuang},
    title = {AlphaForce},
    year = {2019},
    publisher = {GitHub},
    journal = {GitHub repository},
    howpublished = {\url{https://github.com/hashfury42/AlphaForce}},
}
```


text:
# Mocking frameworks or manual fakes?
### This is the code used during SoCraTes Italy 2018

Take a look at the stream of commits, they should make my point clearer.
The main problem is the lack of feedback when I make changes to add/modify a behavior. In the GOOS book the use of a mocking framework is paired with E2E tests, which I rarely see around because they're costly.

# These are some of the concerns expressed during the presentation
Q: But without a mocking framework you can't do outside-in TDD!
A: Nope, not related. You can still do outside-in using manual fakes, I do!

Q: The test using manual fakes is more opaque
A: I respectfully disagree. Tests should not reveal implementation details but express an observable behavior, that's what makes refactoring sustainable

Q: The tests that reuse a manual fakes are a little more coupled, meaning that if you make a mistake in the "InMemory..." fake implementation a bunch of tests will break
A: Yes, that's true and it's a trade-off I'm willing to accept because it hasn't been a problem so far...

Do you have a question or observation to make? Post an issue and I'll try to answer


text:
Cloudinary, Titanium and Parse - Photo Album sample
===================================================

Demo for writing an Titanium application using Parse as a backend and Cloudinary as image backend for storing,
applying transformations and serving of images.

For more details about **Cloudinary**: http://cloudinary.com/

For more details about **Titanium development**: http://www.appcelerator.com/developers/

For more details about **Parse**: https://www.parse.com/

## Setup and run the sample project

* [Sign up](https://cloudinary.com/users/register/free) for a free Cloudinary account
* [Register, download Titanium SDK, setup Titanium Studio and mobile SDKs](http://www.appcelerator.com/developers/)
* [Download](https://github.com/cloudinary/cloudinary_titanium_parse_sample/archive/master.zip) or [clone](https://github.com/cloudinary/cloudinary_titanium_parse_sample.git) this repository into your titanium workspace
* [Setup the Parse backend in 7 simple steps](https://github.com/cloudinary/cloudinary_parse#setup-the-sample-project)
* Copy the `app/lib/config.coffee.sample` file into `app/lib/config.coffee` and modify the configuration within it to reflect your Cloudinary cloud name and your Parse Application ID and Javascript Key.
* Import the project (File -> Import -> Titanium -> Existing Mobile Project -> Project directory -> Browse -> [Choose the cloudinary-titanium-parse-sample path])
* Run the application on an mobile device or a simulator (Run -> Run Configurations -> [Double click preferred run configuration] -> Run)

## How does it work
The application is composed of 4 top-level Alloy controllers (`login`, `list_photos`, `show_photo` and `upload_photo`), a generic grid view class (`app/lib/grid_view`), and a few external libraries.

All code is written in [CoffeeScript](http://coffeescript.org/) and compiled automatically by the titanium-assets plugin.

### Entry points
#### app/alloy.coffee
Invoked by alloy before anything else. It configures Cloudinary and Parse

#### index controller
The default controller that is openned by alloy. It creates and opens `login` controller.

### Upload process
The Cloudinary API key and API secret are protected in Parse cloud code. They are not bundled in the application and are not accessible by any user - making the design more secure and protecting yours and your users' privacy and data integrity.

In order to upload in image from the application:

* A request to upload is sent by the application to Parse backend using a cloud function.
* The cloud function (by default, `sign_upload_request`) creates a signed request (using Cloudinary API parameters) and returns it to the application.
* The application uploads the image to Cloudinary using the retrieved signed request. When the upload is complete, Cloudinary returns a signed result of the operation containing the image public\_id, other identifiers required to access the image and metadata about the image (disk size, dimensions, etc...)
* The application saves the signed reference of the image to Parse backend.
* The Parse beforeSave filter verifies the authenticity of the saved reference and aborts the process if it's invalid.

### Controllers
#### login
Displays a Chuck Norris power icon fetched from the official Facebook profile and transformed by Cloudinary.
Login is done using Parse backend in `doSubmit` function

#### list\_photos
Uses `grid_view` class to display a grid of all items. The collection of images is managed and retrieved using Parse.Collection SDK class (`app\lib\parse_photo_album.coffee`)
Also adds an additional (plus sign) image for uploading new images.

Uses:

* `app/lib/grid_view` library class - A basic framework for displaying a Backbone collection of items using alloy controllers
* `grid_main` controller - Handles whole grid behaviour
* `grid_child` controller - Handles each grid item behaviour

#### show\_photo
Displays a swipeable window with different transformations applied to the selected image

Uses:

* `image_tab` controller - Displays a cloudinary image using an identifier and a transformation object

#### upload\_photo
Invokes native photo gallary to allow user to select an image to upload.
Once the user selects an image, the [upload process](#uploadprocess) begins.

### External libraries
* [Cloudinary-Titanium library](https://github.com/cloudinary/cloudinary_titanium)
* [Ti.Parse](https://github.com/andreaspollak/Ti.Parse)

## Read more

[Cloudinary documentation](http://cloudinary.com/documentation)
[Cloudinary for Titanium](https://github.com/cloudinary/cloudinary_titanium)
[Cloudinary for Parse](https://github.com/cloudinary/cloudinary_parse)

## Support

You can [open an issue through GitHub](https://github.com/cloudinary/cloudinary-android-parse-sample/issues).

Contact us at [info<EMAIL_ADDRESS>
Or via Twitter: [@cloudinary](https://twitter.com/#!/cloudinary)

### Supported platforms
The sample has been tested on Android and iOS platforms.
Due to browser limitations, mobile web won't work with cloudinary

## Licenses

* This project is released under the MIT license.