-
Notifications
You must be signed in to change notification settings - Fork 22
/
faqs.html
661 lines (619 loc) · 59.4 KB
/
faqs.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
<!DOCTYPE html>
<html lang="en" data-content_root="./">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>FAQs — Bioconda documentation</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=fa44fd50" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=39de963d" />
<link rel="stylesheet" type="text/css" href="_static/graphviz.css?v=fd3f3429" />
<link rel="stylesheet" type="text/css" href="_static/style.css?v=48720263" />
<link rel="stylesheet" type="text/css" href="_static/font-awesome-4.7.0/css/font-awesome.min.css?v=02f538dc" />
<script src="_static/documentation_options.js?v=5929fcd5"></script>
<script src="_static/doctools.js?v=9a2dae69"></script>
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
<script src="_static/vega.min.js?v=d54ef115"></script>
<script src="_static/vega-lite.min.js?v=4fab2bf4"></script>
<script src="_static/vega-embed.min.js?v=2f6bc6e4"></script>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="Contributing to Bioconda" href="contributor/index.html" />
<link rel="prev" title="Usage" href="index.html" />
<link href="https://fonts.googleapis.com/css?family=Lato|Raleway" rel="stylesheet">
<link href="https://fonts.googleapis.com/css?family=Inconsolata" rel="stylesheet">
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Raleway:wght@700&display=swap" rel="stylesheet">
<link rel="apple-touch-icon" sizes="57x57" href="_static/apple-icon-57x57.png">
<link rel="apple-touch-icon" sizes="60x60" href="_static/apple-icon-60x60.png">
<link rel="apple-touch-icon" sizes="72x72" href="_static/apple-icon-72x72.png">
<link rel="apple-touch-icon" sizes="76x76" href="_static/apple-icon-76x76.png">
<link rel="apple-touch-icon" sizes="114x114" href="_static/apple-icon-114x114.png">
<link rel="apple-touch-icon" sizes="120x120" href="_static/apple-icon-120x120.png">
<link rel="apple-touch-icon" sizes="144x144" href="_static/apple-icon-144x144.png">
<link rel="apple-touch-icon" sizes="152x152" href="_static/apple-icon-152x152.png">
<link rel="apple-touch-icon" sizes="180x180" href="_static/apple-icon-180x180.png">
<link rel="icon" type="image/png" sizes="192x192" href="_static/android-icon-192x192.png">
<link rel="icon" type="image/png" sizes="32x32" href="_static/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="96x96" href="_static/favicon-96x96.png">
<link rel="icon" type="image/png" sizes="16x16" href="_static/favicon-16x16.png">
<meta name="msapplication-TileColor" content="#ffffff">
<meta name="msapplication-TileImage" content="_static/ms-icon-144x144.png">
<link rel="manifest" href="_static/manifest.json">
<meta name="theme-color" content="#ffffff">
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="faqs">
<h1>FAQs<a class="headerlink" href="#faqs" title="Link to this heading">¶</a></h1>
<nav class="contents local" id="contents">
<ul class="simple">
<li><p><a class="reference internal" href="#how-do-i-speed-up-package-installation" id="id6">How do I speed up package installation?</a></p></li>
<li><p><a class="reference internal" href="#what-versions-are-supported" id="id7">What versions are supported?</a></p></li>
<li><p><a class="reference internal" href="#how-do-i-keep-track-of-environments" id="id8">How do I keep track of environments?</a></p></li>
<li><p><a class="reference internal" href="#what-s-the-difference-between-anaconda-conda-miniconda-mamba-mambaforge-micromamba" id="id9">What’s the difference between Anaconda, conda, Miniconda, mamba, Mambaforge, micromamba?</a></p></li>
<li><p><a class="reference internal" href="#what-s-the-difference-between-a-recipe-and-a-package" id="id10">What’s the difference between a recipe and a package?</a></p></li>
<li><p><a class="reference internal" href="#why-are-bioconductor-data-packages-failing-to-install" id="id11">Why are Bioconductor data packages failing to install?</a></p></li>
<li><p><a class="reference internal" href="#what-s-the-difference-between-a-build-number-and-a-package-version" id="id12">What’s the difference between a build number and a package version?</a></p></li>
<li><p><a class="reference internal" href="#why-shouldn-t-i-include-build-numbers-in-my-environment-yamls" id="id13">Why shouldn’t I include build numbers in my environment YAMLs?</a></p></li>
<li><p><a class="reference internal" href="#how-are-dependencies-pinned-to-particular-versions" id="id14">How are dependencies pinned to particular versions?</a></p></li>
<li><p><a class="reference internal" href="#what-s-the-lifecycle-of-a-bioconda-package" id="id15">What’s the lifecycle of a bioconda package?</a></p></li>
<li><p><a class="reference internal" href="#where-can-i-find-more-info-on-meta-yaml" id="id16">Where can I find more info on <code class="docutils literal notranslate"><span class="pre">meta.yaml</span></code>?</a></p></li>
<li><p><a class="reference internal" href="#what-are-the-host-and-build-sections-of-a-recipe" id="id17">What are the <code class="docutils literal notranslate"><span class="pre">host</span></code> and <code class="docutils literal notranslate"><span class="pre">build</span></code> sections of a recipe?</a></p></li>
<li><p><a class="reference internal" href="#compiler-tools" id="id18">Compiler tools</a></p></li>
<li><p><a class="reference internal" href="#how-does-global-pinning-work" id="id19">How does global pinning work?</a></p></li>
<li><p><a class="reference internal" href="#understanding-platform-nomenclature" id="id20">Understanding platform nomenclature</a></p></li>
</ul>
</nav>
<section id="how-do-i-speed-up-package-installation">
<span id="speedup"></span><h2>How do I speed up package installation?<a class="headerlink" href="#how-do-i-speed-up-package-installation" title="Link to this heading">¶</a></h2>
<section id="speedup-option-1-use-mamba">
<h3>Speedup option 1: use <code class="docutils literal notranslate"><span class="pre">mamba</span></code><a class="headerlink" href="#speedup-option-1-use-mamba" title="Link to this heading">¶</a></h3>
<p><a class="reference external" href="https://github.com/mamba-org/mamba">mamba</a> is a drop-in replacement for
conda that uses a faster dependency solving library and parts reimplemented in
C++ for speed. Install it just into the base environment so that it’s always
available, like this:</p>
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>conda<span class="w"> </span>install<span class="w"> </span>mamba<span class="w"> </span>-n<span class="w"> </span>base<span class="w"> </span>-c<span class="w"> </span>conda-forge
</pre></div>
</div>
<p>Then use <code class="docutils literal notranslate"><span class="pre">mamba</span></code> instead of <code class="docutils literal notranslate"><span class="pre">conda</span></code>.</p>
<p>For example, instead of <code class="docutils literal notranslate"><span class="pre">conda</span> <span class="pre">install</span></code>, use <code class="docutils literal notranslate"><span class="pre">mamba</span> <span class="pre">install</span></code>. Instead of
<code class="docutils literal notranslate"><span class="pre">conda</span> <span class="pre">env</span> <span class="pre">create</span></code> use <code class="docutils literal notranslate"><span class="pre">mamba</span> <span class="pre">env</span> <span class="pre">create</span></code>, and so on. <code class="docutils literal notranslate"><span class="pre">mamba</span></code> also uses
the same configuration as <code class="docutils literal notranslate"><span class="pre">conda</span></code>, so you don’t need to reconfigure the
channels.</p>
<div class="admonition note">
<p class="admonition-title">Note</p>
<p>Installing <code class="docutils literal notranslate"><span class="pre">mamba</span></code> into the base environment (<code class="docutils literal notranslate"><span class="pre">-n</span> <span class="pre">base</span></code> in the command
above) means that it does <strong>not</strong> need to be installed into each subsequent
environment you create.</p>
</div>
</section>
<section id="speedup-option-2-use-environments-strategically">
<h3>Speedup option 2: use environments strategically<a class="headerlink" href="#speedup-option-2-use-environments-strategically" title="Link to this heading">¶</a></h3>
<p>Here are several ways you can use environments to minimize the time spent on
solving dependencies, which typically is what takes the longest amount of time:</p>
<ol class="arabic">
<li><p><strong>Keep the base environment small.</strong></p>
<p>If you install everything into the same environment (e.g. the <code class="docutils literal notranslate"><span class="pre">base</span></code>
environment, which is used any time you don’t otherwise specify an
environment), then whenever you add or update packages to it, the solver has
to do a lot of work to make sure all of the many packages are mutually
compatible with each other.</p>
</li>
<li><p><strong>Use smaller environments.</strong></p>
<p>Fewer packages means less work for the solver. Try to use environments only
containing what you need for a particular project or task.</p>
</li>
<li><p><strong>Pin dependencies.</strong></p>
<p>Sometimes pinning dependencies to a specific version can speed up the
solving, since it reduces the search space for the solver. In some cases
this may backfire though. For example, you can’t pin an older version of
R and also use newer R packages that don’t support that version of R.</p>
</li>
<li><p><strong>Create an environment from a file with all dependencies.</strong></p>
<p>Creating an environment with all dependencies at once can be faster than
incrementally adding packages to an existing environment. For example
<code class="docutils literal notranslate"><span class="pre">conda</span> <span class="pre">create</span> <span class="pre">-n</span> <span class="pre">myenv</span> <span class="pre">--file</span> <span class="pre">requirements.txt</span></code>, or <code class="docutils literal notranslate"><span class="pre">conda</span> <span class="pre">env</span> <span class="pre">create</span>
<span class="pre">--file</span> <span class="pre">env.yaml</span></code>.</p>
</li>
<li><p><strong>Use strict channel priority.</strong></p>
<p>Ensure that you’ve run <code class="docutils literal notranslate"><span class="pre">conda</span> <span class="pre">config</span> <span class="pre">--set</span> <span class="pre">channel_priority</span> <span class="pre">strict</span></code> to
respect the configured channel order, as recommended in the setup
instructions. This can also speed up the solving.</p>
</li>
</ol>
</section>
</section>
<section id="what-versions-are-supported">
<h2>What versions are supported?<a class="headerlink" href="#what-versions-are-supported" title="Link to this heading">¶</a></h2>
<p><strong>Operating Systems:</strong>
Bioconda supports Linux (x86_64 and aarch64/arm64) and
macOS (x86_64 and arm64). Windows is not supported.</p>
<p><strong>Python:</strong>
Bioconda currently supports Python 3.8, 3.9, 3.10, 3.11, and 3.12 (see “pinned packages”
below for where this is configured). There are still packages in the Bioconda
channel for earlier versions of Python (2.7, 3.6, and 3.7), but new packages
are not built for these versions.</p>
<p>Packages which declare <code class="xref any docutils literal notranslate"><span class="pre">noarch:</span> <span class="pre">python</span></code> and only depend on packages that also
declare <code class="xref any docutils literal notranslate"><span class="pre">noarch:</span> <span class="pre">python</span></code> can be installed in an environment with any version of
Python they say they can support. However many Python packages in Bioconda
depend on other Bioconda packages with architecture specific builds, such as
<a class="conda-package reference internal" href="recipes/pysam/README.html#package-pysam" title="pysam package"><code class="xref any conda conda-package docutils literal notranslate"><span class="pre">pysam</span></code></a>, and so do not meet this criteria.</p>
<div class="datechanged">
<p><span class="versionmodified changed">Changed on 2022-09-01: </span>Python 3.10 support started in Aug 2022</p>
</div>
<div class="datechanged">
<p><span class="versionmodified changed">Changed on 2023-05-01: </span>Python 2.7, 3.6, 3.7 support were dropped for new recipes in May 2023</p>
</div>
<div class="datechanged">
<p><span class="versionmodified changed">Changed on 2024-06-15: </span>Python 3.11, 3.12 support started in June 2024</p>
</div>
<p><strong>Globally-pinned versions:</strong> See <a class="reference internal" href="#global-pinning"><span class="std std-ref">How does global pinning work?</span></a> for details.</p>
<p><strong>Unsupported versions:</strong>
If there is a version of a dependency you wish to build against that Bioconda
does not currently support, please reach out to the <a class="reference external" href="https://gitter.im/bioconda/Lobby">Bioconda Gitter</a> for more information about if supporting
that version is feasible, if work on that is already being done, and how you
can help.</p>
<p>To find out against which version you can pin a package, e.g. x.y.* or x.*
please use <a class="reference external" href="https://abi-laboratory.pro/tracker/">ABI-Laboratory</a>.</p>
</section>
<section id="how-do-i-keep-track-of-environments">
<h2>How do I keep track of environments?<a class="headerlink" href="#how-do-i-keep-track-of-environments" title="Link to this heading">¶</a></h2>
<p>You can view your created environments with <code class="docutils literal notranslate"><span class="pre">conda</span> <span class="pre">env</span> <span class="pre">list</span></code>.</p>
<p>Note that if keeping track of different environment names
becomes a burden, you can create an environment in the same directory as
a project with the <code class="docutils literal notranslate"><span class="pre">-p</span></code> argument, e.g.,</p>
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>conda<span class="w"> </span>create<span class="w"> </span>-p<span class="w"> </span>./env<span class="w"> </span>--file<span class="w"> </span>requirements.txt
</pre></div>
</div>
<p>and then activate the environment with</p>
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>conda<span class="w"> </span>activate<span class="w"> </span>./env
</pre></div>
</div>
<p>This also works quite well in a shared directory so everyone can use (and
maintain) the same environment.</p>
</section>
<section id="what-s-the-difference-between-anaconda-conda-miniconda-mamba-mambaforge-micromamba">
<span id="conda-anaconda-minconda"></span><h2>What’s the difference between Anaconda, conda, Miniconda, mamba, Mambaforge, micromamba?<a class="headerlink" href="#what-s-the-difference-between-anaconda-conda-miniconda-mamba-mambaforge-micromamba" title="Link to this heading">¶</a></h2>
<p>This <a class="reference external" href="https://www.anaconda.com/blog/is-conda-free">blog post from Anaconda</a>
gives a lot of context on the Anaconda/conda ecosystem.</p>
<ul class="simple">
<li><p><strong>conda</strong> is the name of the package manager, which is what runs when you call,
e.g., <code class="docutils literal notranslate"><span class="pre">conda</span> <span class="pre">install</span></code>.</p></li>
<li><p><strong>mamba</strong> is a drop-in replacement for conda.</p></li>
<li><p><strong>Anaconda</strong> is a large installation including Python, conda, and a large number
of packages.</p></li>
<li><p><strong>Miniconda</strong> just has conda and its dependencies (in contrast to the larger
Anaconda distribution).</p></li>
<li><p><strong>Miniforge</strong> is like miniconda, but with the conda-forge channel
preconfigured and all packages coming from the conda-forge and <em>not</em> the
<code class="docutils literal notranslate"><span class="pre">defaults</span></code> channel. It also now has mamba and libmamba included.</p></li>
<li><p><strong>Mambaforge</strong> is like miniforge, but has mamba installed into the base
environment. While not strictly deprecated, its use is discouraged as of
Sept 2023 (see <a class="reference external" href="https://github.com/conda-forge/miniforge">miniforge README</a>).</p></li>
<li><p><strong>Micromamba</strong> is not a conda distribution. Rather, it is a minimal binary
that has roughly the same commands as mamba, so that a single executable
(rather than an entire Python installation required for conda itself) can be
used to create environments. Micromamba is currently still experimental.</p></li>
</ul>
<p>The <a class="reference external" href="https://www.continuum.io/downloads">Anaconda Python distribution</a>
started out as a bundle of scientific Python packages that were otherwise
difficult to install. It was created by <a class="reference external" href="https://www.continuum.io/">ContinuumIO</a> and remains the easiest way to install the full
scientific Python stack.</p>
<p>Many packaging problems had to be solved in order to provide all of that
software in Anaconda in a cross-platform bundle, and one of the tools that came
out of that work was the conda package manager. So conda is part of th Anaconda
Python distribution. But conda ended up being very useful on its own and for
things other than Python, so ContinuumIO spun it out into its own separate
<a class="reference external" href="https://github.com/conda/conda">open-source package</a>.</p>
<p>Conda became very useful for setting up lightweight environments for testing
code or running individual steps of a workflow. To avoid needing to install the
<em>entire</em> Anaconda distribution each time, the Miniconda installer was created.
This installs only what you need to run conda itself, which can then be used to
create other environments. So the “mini” in Miniconda means that it’s
a fraction of the size of the full Anaconda installation.</p>
<p>Then the conda-forge channel gained popularity. Miniforge was developed to
quickly and easily get a conda-forge-ready conda installation. Then as mamba
gained popularity, the Mambaforge variant was created.</p>
<p>Even with those easier methods, sometimes the entire base Python installation that comes with conda/mamba was too much overhead. Micromamba has a single binary that is very fast to install, and is perfect for CI environments.</p>
<p>So: conda is a package manager, Anaconda is a scientific Python distribution
that also includes conda, and the rest are other flavors of getting
a conda/mamba installation.</p>
</section>
<section id="what-s-the-difference-between-a-recipe-and-a-package">
<h2>What’s the difference between a recipe and a package?<a class="headerlink" href="#what-s-the-difference-between-a-recipe-and-a-package" title="Link to this heading">¶</a></h2>
<p>A <em>recipe</em> is a directory containing small set of files that defines name,
version, dependencies, and URL for source code. A recipe typically contains
a <code class="docutils literal notranslate"><span class="pre">meta.yaml</span></code> file that defines these settings and a <code class="docutils literal notranslate"><span class="pre">build.sh</span></code> script that
builds the software.</p>
<p>A recipe is converted into a <em>package</em> by running <a class="conda-forge reference external" href="https://github.com/conda-forge/conda-build-feedstock"><code class="xref any conda conda-package docutils literal notranslate"><span class="pre">conda-build</span></code></a> on the recipe.
A package is a bgzipped tar file (<code class="docutils literal notranslate"><span class="pre">.tar.bz2</span></code>) that contains the built
software in expected subdirectories, along with a list of what other packages
are dependencies. For example, a conda package built for a Python package would
end up with <code class="xref any docutils literal notranslate"><span class="pre">.py</span></code> files in the <code class="xref any docutils literal notranslate"><span class="pre">lib/python3.8/site-packages/</span></code>
directory inside the tarball, and would specify (at least) Python as
a dependency.</p>
<p>Packages are uploaded to anaconda.org so that users can install them
with <code class="docutils literal notranslate"><span class="pre">conda</span> <span class="pre">install</span></code>.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p>The <a class="reference external" href="https://conda.io/projects/conda-build/en/latest/resources/package-spec.html" title="(in conda-build v0.0.0.dev0+placeholder)"><code class="docutils literal notranslate"><span class="pre">Conda</span> <span class="pre">package</span> <span class="pre">specification</span></code></a> has details on exactly
what a package contains and how it is installed into an
environment.</p>
</div>
</section>
<section id="why-are-bioconductor-data-packages-failing-to-install">
<h2>Why are Bioconductor data packages failing to install?<a class="headerlink" href="#why-are-bioconductor-data-packages-failing-to-install" title="Link to this heading">¶</a></h2>
<p>When creating an environment containing Bioconductor data packages, you may get
errors like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="ne">ValueError</span><span class="p">:</span> <span class="n">unsupported</span> <span class="nb">format</span> <span class="n">character</span> <span class="s1">'T'</span> <span class="p">(</span><span class="mh">0x54</span><span class="p">)</span> <span class="n">at</span> <span class="n">index</span> <span class="mi">648</span>
</pre></div>
</div>
<p>The actual error will be somewhere above that, with something like this (here,
it’s for the <code class="docutils literal notranslate"><span class="pre">bioconductor-org.hs.eg.db=3.14.0=r41hdfd78af_0</span></code> package):</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">message</span><span class="p">:</span>
<span class="n">post</span><span class="o">-</span><span class="n">link</span> <span class="n">script</span> <span class="n">failed</span> <span class="k">for</span> <span class="n">package</span> <span class="n">bioconda</span><span class="p">::</span><span class="n">bioconductor</span><span class="o">-</span><span class="n">org</span><span class="o">.</span><span class="n">hs</span><span class="o">.</span><span class="n">eg</span><span class="o">.</span><span class="n">db</span><span class="o">-</span><span class="mf">3.14.0</span><span class="o">-</span><span class="n">r41hdfd78af_0</span>
<span class="n">location</span> <span class="n">of</span> <span class="n">failed</span> <span class="n">script</span><span class="p">:</span> <span class="o">/</span><span class="n">Users</span><span class="o">/</span><span class="n">dalerr</span><span class="o">/</span><span class="n">env</span><span class="o">/</span><span class="nb">bin</span><span class="o">/.</span><span class="n">bioconductor</span><span class="o">-</span><span class="n">org</span><span class="o">.</span><span class="n">hs</span><span class="o">.</span><span class="n">eg</span><span class="o">.</span><span class="n">db</span><span class="o">-</span><span class="n">post</span><span class="o">-</span><span class="n">link</span><span class="o">.</span><span class="n">sh</span>
<span class="o">==></span> <span class="n">script</span> <span class="n">messages</span> <span class="o"><==</span>
<span class="o"><</span><span class="kc">None</span><span class="o">></span>
<span class="o">==></span> <span class="n">script</span> <span class="n">output</span> <span class="o"><==</span>
<span class="n">stdout</span><span class="p">:</span> <span class="n">ERROR</span><span class="p">:</span> <span class="n">post</span><span class="o">-</span><span class="n">link</span><span class="o">.</span><span class="n">sh</span> <span class="n">was</span> <span class="n">unable</span> <span class="n">to</span> <span class="n">download</span> <span class="nb">any</span> <span class="n">of</span> <span class="n">the</span> <span class="n">following</span> <span class="n">URLs</span> <span class="k">with</span> <span class="n">the</span> <span class="n">md5sum</span> <span class="n">ef7fc0096ec579f564a33f0f4869324a</span><span class="p">:</span>
<span class="n">https</span><span class="p">:</span><span class="o">//</span><span class="n">bioconductor</span><span class="o">.</span><span class="n">org</span><span class="o">/</span><span class="n">packages</span><span class="o">/</span><span class="mf">3.14</span><span class="o">/</span><span class="n">data</span><span class="o">/</span><span class="n">annotation</span><span class="o">/</span><span class="n">src</span><span class="o">/</span><span class="n">contrib</span><span class="o">/</span><span class="n">org</span><span class="o">.</span><span class="n">Hs</span><span class="o">.</span><span class="n">eg</span><span class="o">.</span><span class="n">db_3</span><span class="mf">.14.0</span><span class="o">.</span><span class="n">tar</span><span class="o">.</span><span class="n">gz</span>
<span class="n">https</span><span class="p">:</span><span class="o">//</span><span class="n">bioarchive</span><span class="o">.</span><span class="n">galaxyproject</span><span class="o">.</span><span class="n">org</span><span class="o">/</span><span class="n">org</span><span class="o">.</span><span class="n">Hs</span><span class="o">.</span><span class="n">eg</span><span class="o">.</span><span class="n">db_3</span><span class="mf">.14.0</span><span class="o">.</span><span class="n">tar</span><span class="o">.</span><span class="n">gz</span>
<span class="n">https</span><span class="p">:</span><span class="o">//</span><span class="n">depot</span><span class="o">.</span><span class="n">galaxyproject</span><span class="o">.</span><span class="n">org</span><span class="o">/</span><span class="n">software</span><span class="o">/</span><span class="n">bioconductor</span><span class="o">-</span><span class="n">org</span><span class="o">.</span><span class="n">hs</span><span class="o">.</span><span class="n">eg</span><span class="o">.</span><span class="n">db</span><span class="o">/</span><span class="n">bioconductor</span><span class="o">-</span><span class="n">org</span><span class="o">.</span><span class="n">hs</span><span class="o">.</span><span class="n">eg</span><span class="o">.</span><span class="n">db_3</span><span class="mf">.14.0</span><span class="n">_src_all</span><span class="o">.</span><span class="n">tar</span><span class="o">.</span><span class="n">gz</span>
</pre></div>
</div>
<p><strong>To fix it</strong>, you need to adjust the requirements. If you had this as a requirement:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bioconductor</span><span class="o">-</span><span class="n">org</span><span class="o">.</span><span class="n">hs</span><span class="o">.</span><span class="n">eg</span><span class="o">.</span><span class="n">db</span><span class="o">=</span><span class="mf">3.14.0</span><span class="o">=</span><span class="n">r41hdfd78af_0</span>
</pre></div>
</div>
<p>then increase the build number on the end, here from <code class="docutils literal notranslate"><span class="pre">_0</span></code> to <code class="docutils literal notranslate"><span class="pre">_1</span></code>:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bioconductor</span><span class="o">-</span><span class="n">org</span><span class="o">.</span><span class="n">hs</span><span class="o">.</span><span class="n">eg</span><span class="o">.</span><span class="n">db</span><span class="o">=</span><span class="mf">3.14.0</span><span class="o">=</span><span class="n">r41hdfd78af_1</span>
</pre></div>
</div>
<p>or, relax the exact build constraint while keeping the package version the same:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bioconductor</span><span class="o">-</span><span class="n">org</span><span class="o">.</span><span class="n">hs</span><span class="o">.</span><span class="n">eg</span><span class="o">.</span><span class="n">db</span><span class="o">=</span><span class="mf">3.14.0</span>
</pre></div>
</div>
<p>and then re-build your environment.</p>
<p><strong>The reason this is happening</strong> is a combination of factors. Early on in
Bioconda’s history we made the decision that pure data packages – like
Bioconductor data packages, which can be multiple GB in size – would not be
directly converted into conda packages. That way, we could avoid additional
storage load on Anaconda’s servers since the data were already available from
Bioconductor, and we could provide a mechanism to use the data packages within
an R environment living in a conda environment. This mechanism is
a <a class="reference external" href="https://docs.conda.io/projects/conda-build/en/latest/resources/link-scripts.html">post-link.sh</a>
script for the recipe.</p>
<p>When a user installs the package via conda, the GB of data aren’t in the
package. Rather, the URL pointing to the tarball is in the post-link script,
and the script uses <code class="docutils literal notranslate"><span class="pre">curl</span></code> to download the package from Bioconductor and
install into the conda environment’s R library. We also set up separate
infrastructure to archive data packages to other servers, and these archive
URLs were also stored in the post-link scripts as backups.</p>
<p><em>The problem is that back then, we assumed that URLs would be stable and we did
not use the</em> <code class="docutils literal notranslate"><span class="pre">-L</span></code> <em>argument for curl in post-link scripts</em>.</p>
<p>Recently Bioconductor packages have moved to a different server (XSEDE/ACCESS).
The old URL, the one hard-coded in the post-link scripts, is correctly now
a redirect to the new location. But without <code class="docutils literal notranslate"><span class="pre">-L</span></code>, the existing recipes and
their post-link scripts cannot follow the redirect! Compounding this, the
archive URLs stopped being generated, so the backup strategy also failed.</p>
<p>The fix was to re-build all Bioconductor data packages and include the <code class="docutils literal notranslate"><span class="pre">-L</span></code>
argument, allowing them to follow the redirect and correctly install the
package. Conda packages have the idea of a “build number”, which allows us to
still provide the same version of the package (3.14.0 in the example above) but
packaged differently (in this case, with a post-link script that works in
Bioconductor’s current server environment).</p>
<p><strong>Reproducibility is hard.</strong> We are trying our best, and conda is an amazing
resource. But the fact that a single entity does not (and should not!) control
all code, data, packages, distribution mechanisms, and installation mechanisms,
means that we will always be at risk of similar situations in the future.
Hopefully we are guarding better against this particular issue, but see
<a class="reference external" href="http://dx.doi.org/10.1016/j.cels.2018.03.014">Grüning et al 2018</a>
(especially Fig 1) for advice on more reproducible strategies you can use for
your own work.</p>
</section>
<section id="what-s-the-difference-between-a-build-number-and-a-package-version">
<span id="version-vs-build"></span><h2>What’s the difference between a build number and a package version?<a class="headerlink" href="#what-s-the-difference-between-a-build-number-and-a-package-version" title="Link to this heading">¶</a></h2>
<p>A <em>package version</em> is the version of the tool. A tool can possibly be packaged
multiple times, even though the underlying tool doesn’t change. In such a case,
the package version remains unchanged, but the <em>build number</em> chances.</p>
<p>The Bioconductor data packages described above are one example of what would
cause a change in build number (i.e., adding a single argument to
a post-installation script). Other times, a package might have omitted an
executable that should have been included, so a new build for the same version
is created that fixes that packaging issue, without changing anything in the
package itself. In rare cases, packages are completely broken, and are moved to
a “broken” label in the conda channel, effectively removing them from being
installed by default.</p>
<p>More often, build numbers change due to underlying dependencies across the
entire Bioconda and conda-forge ecosystem. These build numbers include a hash.
That hash is generated by concatenating all of the pinned versions of packages
that are dependencies of that package.</p>
<p>For example, <code class="docutils literal notranslate"><span class="pre">samtools==1.15.1=h1170115_0</span></code> refers to version 1.15.1 of
<code class="docutils literal notranslate"><span class="pre">samtools</span></code>. The build number is <code class="docutils literal notranslate"><span class="pre">h1170115_0</span></code>. The hash part is the
<code class="docutils literal notranslate"><span class="pre">h1170115</span></code>, and the <code class="docutils literal notranslate"><span class="pre">_0</span></code> refers to the first (zero-indexing) build of this
samtools version and this hash.</p>
<p>The hash, in turn is calculated by looking at the dependencies of samtools. The
dependencies happen to include things like a C compiler (gcc), the zlib and htslib
libraries and make. Some of these dependencies are “pinned”. That is, they are
fixed to a particular version or versions, and those versions are used
everywhere in conda-forge and Bioconda to maintain ABI compatibility
(basically, to let packages co-exist in the same environment). You can find the
conda-forge pinnings <a class="reference external" href="https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/main/recipe/conda_build_config.yaml">here</a>,
and the bioconda-specific ones <a class="reference external" href="https://github.com/bioconda/bioconda-utils/blob/master/bioconda_utils/bioconda_utils-conda_build_config.yaml">here</a>.</p>
<p>In the case of samtools, that hash <code class="docutils literal notranslate"><span class="pre">h1170115</span></code> incorporates the packages and
versions of all of its dependencies that are pinned. That includes gcc, zlib,
and htslib. But it doesn’t include make in that hash, because make is not
pinned in those files.</p>
<p>The build number is likely to change, and you probably should avoid including
the build number in your environment specifications – see <a class="reference internal" href="#no-builds"><span class="std std-ref">Why shouldn’t I include build numbers in my environment YAMLs?</span></a> for
more information on this.</p>
</section>
<section id="why-shouldn-t-i-include-build-numbers-in-my-environment-yamls">
<span id="no-builds"></span><h2>Why shouldn’t I include build numbers in my environment YAMLs?<a class="headerlink" href="#why-shouldn-t-i-include-build-numbers-in-my-environment-yamls" title="Link to this heading">¶</a></h2>
<p>As described at <a class="reference internal" href="#version-vs-build"><span class="std std-ref">What’s the difference between a build number and a package version?</span></a>, build numbers may change over time,
independently of the actual package version. This means that when you are
recording the packages installed in an environment, it is not useful to record
the build number, as this is effectively over-specifying and may cause
difficulty when trying to re-create the environment.</p>
<p>To record the installed packages in an environment, we recommend the
<code class="docutils literal notranslate"><span class="pre">--no-builds</span></code> argument to <code class="docutils literal notranslate"><span class="pre">conda</span> <span class="pre">env</span> <span class="pre">export</span></code>. For example, with an
environment activated:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">conda</span> <span class="n">env</span> <span class="n">export</span> <span class="o">--</span><span class="n">no</span><span class="o">-</span><span class="n">builds</span>
</pre></div>
</div>
<p>The <code class="docutils literal notranslate"><span class="pre">--no-builds</span></code> argument completely removes the build number from the
output, avoiding future errors when trying to rebuild the environment, and
allowing the conda solver to identify the packages that can co-exist in the
same environment.</p>
</section>
<section id="how-are-dependencies-pinned-to-particular-versions">
<h2>How are dependencies pinned to particular versions?<a class="headerlink" href="#how-are-dependencies-pinned-to-particular-versions" title="Link to this heading">¶</a></h2>
<p>In some cases a recipe may need to pin the version of a dependency.
A global set of default versions to pin against is shared with conda-forge and
can be found <a class="reference external" href="https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/conda_build_config.yaml">here</a>.
For new dependencies that are contained in conda-forge and not yet in this list,
please update the list via a pull request.
Local pinnings can be achieved by adding a file <code class="docutils literal notranslate"><span class="pre">conda_build_config.yaml</span></code> next
to your <code class="docutils literal notranslate"><span class="pre">meta.yaml</span></code>.</p>
<p>To find out against which version you can pin a package, e.g. x.y.* or x.* please use <a class="reference external" href="https://abi-laboratory.pro/tracker/">ABI-Laboratory</a>.</p>
</section>
<section id="what-s-the-lifecycle-of-a-bioconda-package">
<h2>What’s the lifecycle of a bioconda package?<a class="headerlink" href="#what-s-the-lifecycle-of-a-bioconda-package" title="Link to this heading">¶</a></h2>
<ul class="simple">
<li><p>Submit a pull request with a new recipe or an updated recipe</p></li>
<li><p>CI (see <a class="reference internal" href="developer/ci-inventory.html#ci-inventory"><span class="std std-ref">CI Inventory</span></a>) automatically builds and tests the changed
recipe[s] using conda-build. Test results are shown on the PR.</p></li>
<li><p>If tests fail, push changes to PR until they pass.</p></li>
<li><p>Once tests pass, merge into master branch</p></li>
<li><p>CI tests again, but this time after testing the built packages are
uploaded to the bioconda channel on anaconda.org.</p></li>
<li><p>Users can now install the package just like any other conda package with
<code class="docutils literal notranslate"><span class="pre">conda</span> <span class="pre">install</span></code>.</p></li>
</ul>
<p>Once uploaded to anaconda.org, it is our intention to never delete any old
packages. Even if a recipe in the bioconda repo is updated to a new version,
the old version will remain on anaconda.org. ContinuumIO has graciously agreed
to sponsor the storage required by the bioconda channel.
Nevertheless, it can sometimes happen that we have to mark packages as broken
in order to avoid that they are accidentally pulled by the conda solver.
In such a case it is only possible to install them by specifically considering
the <code class="docutils literal notranslate"><span class="pre">broken</span></code> label, i.e.,</p>
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>conda<span class="w"> </span>install<span class="w"> </span>-c<span class="w"> </span>conda-forge<span class="w"> </span>-c<span class="w"> </span>bioconda<span class="w"> </span>-c<span class="w"> </span>defaults<span class="w"> </span>-c<span class="w"> </span>bioconda/label/broken<span class="w"> </span>my-package<span class="o">=</span><broken-version>
</pre></div>
</div>
</section>
<section id="where-can-i-find-more-info-on-meta-yaml">
<h2>Where can I find more info on <code class="docutils literal notranslate"><span class="pre">meta.yaml</span></code>?<a class="headerlink" href="#where-can-i-find-more-info-on-meta-yaml" title="Link to this heading">¶</a></h2>
<p>The <code class="docutils literal notranslate"><span class="pre">meta.yaml</span></code> file is conda’s metadata definition file for recipes.
If you are developing a new recipe or are trying to update or improve an existing one, it can be helpful to know
which elements and values can appear in <code class="docutils literal notranslate"><span class="pre">meta.yaml</span></code>.</p>
<p>Conda has this information available <a class="reference external" href="https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html">here</a>.
Please check that you are looking at the correct version of the documentation
for the current conda version used by bioconda.</p>
</section>
<section id="what-are-the-host-and-build-sections-of-a-recipe">
<h2>What are the <code class="docutils literal notranslate"><span class="pre">host</span></code> and <code class="docutils literal notranslate"><span class="pre">build</span></code> sections of a recipe?<a class="headerlink" href="#what-are-the-host-and-build-sections-of-a-recipe" title="Link to this heading">¶</a></h2>
<p>The <code class="docutils literal notranslate"><span class="pre">requirements:build</span></code> section of a meta.yaml file is used to specify the
tools for <em>building</em> the package, but not necessarily for <em>running</em> it. This is
where compilers should go. The build section might also include tools like
<code class="docutils literal notranslate"><span class="pre">make</span></code>, <code class="docutils literal notranslate"><span class="pre">automake</span></code>, <code class="docutils literal notranslate"><span class="pre">cmake</span></code>, or <code class="docutils literal notranslate"><span class="pre">git</span></code>. If there are no compilers or
other build tools, there should be no <code class="docutils literal notranslate"><span class="pre">build:</span></code> section.</p>
<p>The <code class="docutils literal notranslate"><span class="pre">requirements:host</span></code> section is used to specify <em>shared libraries</em>. It was
originally introduced to support cross-compiling (e.g., build on linux-64 but
output a package to be used on linux-aarch64) and the shared libraries here are
what’s needed on the target (e.g. linux-aarch64 in this example). In practice,
this is where the base interpreter <code class="docutils literal notranslate"><span class="pre">python</span></code> or <code class="docutils literal notranslate"><span class="pre">r-base</span></code> should go for
Python and R packages. <code class="docutils literal notranslate"><span class="pre">pip</span></code> is usually here as well, and <code class="docutils literal notranslate"><span class="pre">setuptools</span></code> if
it is required for the build process. <code class="docutils literal notranslate"><span class="pre">cython</span></code> would go here. If a package
<a class="reference external" href="https://conda-forge.org/docs/maintainer/knowledge_base.html#building-against-numpy">builds against numpy</a>,
then <code class="docutils literal notranslate"><span class="pre">numpy</span></code> should go here (otherwise, it should go in the <code class="docutils literal notranslate"><span class="pre">run:</span></code>
requirements). Shared libraries like <code class="docutils literal notranslate"><span class="pre">zlib</span></code>, <code class="docutils literal notranslate"><span class="pre">hdf5</span></code>, <code class="docutils literal notranslate"><span class="pre">libcurl</span></code>, and
<code class="docutils literal notranslate"><span class="pre">htslib</span></code> should go here in <code class="docutils literal notranslate"><span class="pre">requirements:host</span></code>.</p>
<p>The <code class="docutils literal notranslate"><span class="pre">requirements:run</span></code> section of a meta.yaml is used to specify the
<em>runtime</em> dependencies of the package.</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<p>See the <a class="reference external" href="https://conda.io/projects/conda-build/en/latest/resources/define-metadata.html#requirements" title="(in conda-build v0.0.0.dev0+placeholder)"><code class="xref any docutils literal notranslate"><span class="pre">requirements</span> <span class="pre">section</span></code></a> of the
conda docs for more info.</p>
</div>
</section>
<section id="compiler-tools">
<span id="id5"></span><h2>Compiler tools<a class="headerlink" href="#compiler-tools" title="Link to this heading">¶</a></h2>
<p>Use the syntax <code class="docutils literal notranslate"><span class="pre">{{</span> <span class="pre">compiler('c')</span> <span class="pre">}}</span></code>, <code class="docutils literal notranslate"><span class="pre">{{</span> <span class="pre">compiler('cxx')</span> <span class="pre">}}</span></code>, and/or <code class="docutils literal notranslate"><span class="pre">{{</span>
<span class="pre">compiler('fortran')</span> <span class="pre">}}</span></code>. These should go in the <code class="docutils literal notranslate"><span class="pre">build</span></code> section, and all
other build dependencies should go in the <code class="docutils literal notranslate"><span class="pre">host</span></code> section.</p>
<p>Anaconda provides platform-specific compilers that are automatically
determined. The string <code class="docutils literal notranslate"><span class="pre">{{</span> <span class="pre">compiler('c')</span> <span class="pre">}}</span></code> will resolve to <code class="docutils literal notranslate"><span class="pre">gcc</span></code> on
Linux, but <code class="docutils literal notranslate"><span class="pre">clang</span></code> on macOS (osx-64).</p>
<div class="admonition seealso">
<p class="admonition-title">See also</p>
<ul class="simple">
<li><p>The <a class="reference external" href="https://conda.io/projects/conda-build/en/latest/resources/compiler-tools.html#compiler-tools" title="(in conda-build v0.0.0.dev0+placeholder)"><code class="xref any docutils literal notranslate"><span class="pre">compiler</span> <span class="pre">tools</span></code></a> section of the
conda docs has much more info.</p></li>
<li><p>The default compiler options are defined by conda-build in the
<a class="reference external" href="https://github.com/conda/conda-build/blob/master/conda_build/variants.py#L42">variants.DEFAULT_COMPILERS</a>
variable.</p></li>
<li><p>More details on “strong” and “weak” exports (using examples of
libpng and libgcc) can be found in the <a class="reference external" href="https://conda.io/projects/conda-build/en/latest/resources/define-metadata.html#run-exports" title="(in conda-build v0.0.0.dev0+placeholder)"><code class="xref any docutils literal notranslate"><span class="pre">export</span> <span class="pre">runtime</span>
<span class="pre">requirements</span></code></a> conda documentation.</p></li>
</ul>
</div>
</section>
<section id="how-does-global-pinning-work">
<span id="global-pinning"></span><h2>How does global pinning work?<a class="headerlink" href="#how-does-global-pinning-work" title="Link to this heading">¶</a></h2>
<p>We can have conflicts when the version of a common library used when the
package is originally <em>built</em> differs from the version when the package is
<em>installed</em>. All packages intending to be installed into the same environment
should be built using the same versions of common libraries so that they can
co-exist. <strong>Global pinning</strong> is the idea of making sure all recipes use the
same versions of common libraries.</p>
<p>For example, many bioinformatics tools have <code class="docutils literal notranslate"><span class="pre">zlib</span></code> as a dependency.
The version of <code class="docutils literal notranslate"><span class="pre">zlib</span></code> used when building the package should be the same as the
version used when installing the package into a new environment. This implies
that we need to specify the <code class="docutils literal notranslate"><span class="pre">zlib</span></code> version in one place and have <em>all recipes
intended to coexist in the same environment</em> use that version.</p>
<p>This is configured with special build config files. Since we rely heavily on
the conda-forge channel, the bioconda build system installs the conda-forge
<a class="reference external" href="https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/conda_build_config.yaml">conda_build_config.yaml</a>
into our build environment so that it can be used for building all recipes.
This is then combined with the bioconda-specific
<a class="reference external" href="https://github.com/bioconda/bioconda-utils/blob/master/bioconda_utils/bioconda_utils-conda_build_config.yaml">bioconda-Utils-conda_build_config.yaml</a>.
Note that in some cases the bioconda config may override some of the
conda-forge configs. For example, historically, we did this when we wanted to
support older Python versions.</p>
<p>The idea here is to specify that any time a dependency (<code class="docutils literal notranslate"><span class="pre">zlib</span></code>, in our
running example) is used as a build dependency, it should also be automatically
be installed as a run dependency without having to explicitly add it as such in
the recipe. This specification is done in the <code class="docutils literal notranslate"><span class="pre">zlib</span></code> recipe itself (which is
hosted by conda-forge), so in general bioconda collaborators can just add
<code class="docutils literal notranslate"><span class="pre">zlib</span></code> as a build dependency.</p>
<p>Note that we don’t have to specify the version of <code class="docutils literal notranslate"><span class="pre">zlib</span></code> in the recipe – it
is pinned in that <code class="docutils literal notranslate"><span class="pre">conda_build_config.yaml</span></code> file we share with conda-forge.</p>
<p>In a similar fashion, the reason that we don’t have to specify <code class="docutils literal notranslate"><span class="pre">libgcc</span></code> as
a <em>run</em> dependency is that <code class="docutils literal notranslate"><span class="pre">{{</span> <span class="pre">compiler('c')</span> <span class="pre">}}</span></code> automatically exports
<code class="docutils literal notranslate"><span class="pre">libgcc</span></code> as a run dependency of any package that uses the C compiler to
build.</p>
</section>
<section id="understanding-platform-nomenclature">
<span id="platform-nomenclature-faq"></span><h2>Understanding platform nomenclature<a class="headerlink" href="#understanding-platform-nomenclature" title="Link to this heading">¶</a></h2>
<div class="datechanged">
<p><span class="versionmodified changed">Changed on 2024-03-04: </span>Added section</p>
</div>
<p>Different CPU chips use different architecture, so programs are written
fundamentally differently for them. A package with compiled dependencies must
therefore use platform-specific dependencies.</p>
<p>There is a lot of confusing nomenclature surrounding them. Here is an attempt
at clearing them up, or at least providing enough context that you can look up
more details on your own:</p>
<p><strong>ISA, instruction set, CISC, RISC, RISC-V</strong>: The <em>instruction set</em> is the assembly
code commands that are possible for the chip. <em>CISC</em> is “complex instruction
set computer” which prioritizes flexibility. <em>RISC</em> is “reduced instruction set
computer” which prioritizing power consumption (this is an oversimplification,
but that’s the general idea). Instruction sets can be proprietary. <a class="reference external" href="https://arm.com/company">Arm</a> is a company that licenses a widely-used
proprietary reduced instruction set. RISC-V is an open (non-proprietary)
reduced instruction set.</p>
<p><strong>Arm vs ARM:</strong> Arm is the company that licenses the proprietary instruction
set. For example, they license it to Apple to run on their M-series chips. ARM
(in all caps) refers to the family of RISC instruction sets, and by extension
chips that use the instruction sets. It is also an acronym for Advanced RISC
Machines and the eariler Acorn RISC Machine. This <a class="reference external" href="https://nickdesaulniers.github.io/blog/2023/03/10/disambiguating-arm/">blog post</a> goes
into lots more detail.</p>
<p><code class="docutils literal notranslate"><span class="pre">x86_64</span></code>, <code class="docutils literal notranslate"><span class="pre">amd64</span></code>: These are synonyms for the original Intel/AMD
architecture.</p>
<p><code class="docutils literal notranslate"><span class="pre">linux/x86_64</span></code>, <code class="docutils literal notranslate"><span class="pre">linux/arm64</span></code>, <code class="docutils literal notranslate"><span class="pre">darwin/amd64</span></code>: These are the platform
designators when using Docker (see <a class="reference external" href="https://docs.docker.com/build/building/multi-platform/">multi-platform images</a> in the Docker
documentation).</p>
<p><code class="docutils literal notranslate"><span class="pre">linux-64</span></code>, <code class="docutils literal notranslate"><span class="pre">linux-aarch64</span></code>, <code class="docutils literal notranslate"><span class="pre">osx-64</span></code>, <code class="docutils literal notranslate"><span class="pre">osx-arm64</span></code>: These are the
platform designators used by conda in channels hosted by Anaconda.</p>
<p><code class="docutils literal notranslate"><span class="pre">aarch64</span></code>, <code class="docutils literal notranslate"><span class="pre">arm64</span></code>: These are synonyms for ARM 64-bit architecture.</p>
<p><strong>M1, M2, M3, Apple Silicon</strong>: These are chips made by Apple and used in Macs.
Apple licenses the ARM RISC, so they are considered aarch64 or arm64.</p>
</section>
</section>
</div>
</div>
</div>
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo">
<a href="index.html">
<img class="logo" src="_static/logo/bioconda_monochrome_small.png" alt="Logo" />
</a>
</p>
<h3>Navigation</h3>
<ul class="current">
<li class="toctree-l1 current"><a class="current reference internal" href="#">FAQs</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#how-do-i-speed-up-package-installation">How do I speed up package installation?</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#speedup-option-1-use-mamba">Speedup option 1: use <code class="docutils literal notranslate"><span class="pre">mamba</span></code></a></li>
<li class="toctree-l3"><a class="reference internal" href="#speedup-option-2-use-environments-strategically">Speedup option 2: use environments strategically</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="#what-versions-are-supported">What versions are supported?</a></li>
<li class="toctree-l2"><a class="reference internal" href="#how-do-i-keep-track-of-environments">How do I keep track of environments?</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-s-the-difference-between-anaconda-conda-miniconda-mamba-mambaforge-micromamba">What’s the difference between Anaconda, conda, Miniconda, mamba, Mambaforge, micromamba?</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-s-the-difference-between-a-recipe-and-a-package">What’s the difference between a recipe and a package?</a></li>
<li class="toctree-l2"><a class="reference internal" href="#why-are-bioconductor-data-packages-failing-to-install">Why are Bioconductor data packages failing to install?</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-s-the-difference-between-a-build-number-and-a-package-version">What’s the difference between a build number and a package version?</a></li>
<li class="toctree-l2"><a class="reference internal" href="#why-shouldn-t-i-include-build-numbers-in-my-environment-yamls">Why shouldn’t I include build numbers in my environment YAMLs?</a></li>
<li class="toctree-l2"><a class="reference internal" href="#how-are-dependencies-pinned-to-particular-versions">How are dependencies pinned to particular versions?</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-s-the-lifecycle-of-a-bioconda-package">What’s the lifecycle of a bioconda package?</a></li>
<li class="toctree-l2"><a class="reference internal" href="#where-can-i-find-more-info-on-meta-yaml">Where can I find more info on <code class="docutils literal notranslate"><span class="pre">meta.yaml</span></code>?</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-are-the-host-and-build-sections-of-a-recipe">What are the <code class="docutils literal notranslate"><span class="pre">host</span></code> and <code class="docutils literal notranslate"><span class="pre">build</span></code> sections of a recipe?</a></li>
<li class="toctree-l2"><a class="reference internal" href="#compiler-tools">Compiler tools</a></li>
<li class="toctree-l2"><a class="reference internal" href="#how-does-global-pinning-work">How does global pinning work?</a></li>
<li class="toctree-l2"><a class="reference internal" href="#understanding-platform-nomenclature">Understanding platform nomenclature</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="contributor/index.html">Contributing to Bioconda</a></li>
<li class="toctree-l1"><a class="reference internal" href="developer/index.html">Developer Docs</a></li>
<li class="toctree-l1"><a class="reference internal" href="tutorials/index.html">Tutorials</a></li>
</ul>
<ul>
<li class="toctree-l1"><a href="conda-package_index.html">Browse packages</a></li>
<li class="toctree-l1"><a href="https://github.com/bioconda/bioconda-recipes">Bioconda @ Github</a></li>
<li class="toctree-l1"><a href="https://gitter.im/bioconda/Lobby"><img alt="Gitter" src="https://img.shields.io/gitter/room/bioconda/Lobby.svg"></a></li>
</ul>
<div id="searchbox" style="display: none" role="search">
<h3 id="searchlabel">Search</h3>
<p id="searchdesc">packages & docs</p>
<div class="searchformwrapper">
<form class="search" action="search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
<input type="submit" value="Go" />
</form>
</div>
</div>
<script>document.getElementById('searchbox').style.display = "block"</script>
</div>
</div>
<div class="clearer"></div>
</div><script>
let closest;
// Get the last part of the URL after the # symbol - should match the div id to display
let id = window.location.hash.substring(1);
let elem = document.getElementById(id);
if (elem != null) {
// Get the closest "details" element and open it
closest = elem.closest("details");
if (closest) closest.open = true;
}
</script>
<div class="footer">
©2016-2024, The Bioconda Team.
|
Powered by <a href="https://www.sphinx-doc.org/">Sphinx 8.0.2</a>
& <a href="https://alabaster.readthedocs.io">Alabaster 0.7.16</a>
|
<a href="_sources/faqs.rst.txt"
rel="nofollow">Page source</a>
</div>
<div class="git-ribbon">
<a href="https://github.com/bioconda/bioconda-docs/edit/main/source/faqs.rst" rel="me">Edit me on GitHub</a>
</div>
</body>
</html>