pybiolib 1.2.802__py3-none-any.whl → 1.2.814__py3-none-any.whl
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- biolib/_internal/llm_instructions/.github/instructions/general-app-knowledge.instructions.md +10 -0
- biolib/_internal/llm_instructions/.github/instructions/style-general.instructions.md +15 -0
- biolib/_internal/llm_instructions/.github/instructions/style-python.instructions.md +16 -0
- biolib/_internal/llm_instructions/.github/instructions/style-react-ts.instructions.md +22 -0
- biolib/_internal/llm_instructions/.github/prompts/biolib_app_inputs.prompt.md +9 -58
- biolib/_internal/llm_instructions/.github/prompts/biolib_run_apps.prompt.md +12 -302
- {pybiolib-1.2.802.dist-info → pybiolib-1.2.814.dist-info}/METADATA +1 -1
- {pybiolib-1.2.802.dist-info → pybiolib-1.2.814.dist-info}/RECORD +11 -9
- biolib/_internal/llm_instructions/.github/instructions/code-style.md +0 -13
- biolib/_internal/llm_instructions/.github/instructions/copilot-instructions.md +0 -9
- {pybiolib-1.2.802.dist-info → pybiolib-1.2.814.dist-info}/LICENSE +0 -0
- {pybiolib-1.2.802.dist-info → pybiolib-1.2.814.dist-info}/WHEEL +0 -0
- {pybiolib-1.2.802.dist-info → pybiolib-1.2.814.dist-info}/entry_points.txt +0 -0
@@ -0,0 +1,10 @@
|
|
1
|
+
---
|
2
|
+
applyTo: "**"
|
3
|
+
---
|
4
|
+
|
5
|
+
You are writing code that runs inside a BioLib app. In general, most BioLib apps are structured such that there is a `run.py` or `main.py` file that contains the main function.
|
6
|
+
Other files are usually helper files that contain functions that are called from the main function.
|
7
|
+
|
8
|
+
BioLib apps often contain a Vite React Typescript project that compiles to a single HTML file used to render interactive and visual output.
|
9
|
+
|
10
|
+
BioLib apps run inside a Docker container, which is built from the `Dockerfile` in the root of the app.
|
@@ -0,0 +1,15 @@
|
|
1
|
+
---
|
2
|
+
applyTo: '**'
|
3
|
+
---
|
4
|
+
|
5
|
+
# General Coding Guidelines
|
6
|
+
- Variable names are allowed to be verbose, and should be descriptive.
|
7
|
+
- Unit tests are not necessary. Tests should instead be written as simple examples demonstrating the functionality of relevant functions.
|
8
|
+
- Always use 4 spaces for indentation.
|
9
|
+
- Function definitions should be typed as specifically as possible.
|
10
|
+
|
11
|
+
# Code Comment Guidelines
|
12
|
+
- Code comments should only be added for complex logic or unintuitive code that is not adequately explained by the function names themselves.
|
13
|
+
- Avoid comments that simply restate what the code does.
|
14
|
+
- When writing comments explaining some non-trivial logic, explain blocks of code rather than individual lines.
|
15
|
+
- Explain changes to the code in chat, not in comments.
|
@@ -0,0 +1,16 @@
|
|
1
|
+
---
|
2
|
+
applyTo: '**/*.py'
|
3
|
+
---
|
4
|
+
|
5
|
+
Apply the [general coding guidelines](./style-general.instructions.md) to all code.
|
6
|
+
|
7
|
+
# Python-specific code style guidelines
|
8
|
+
- Use snake_case for function and variable names, and PascalCase for class names.
|
9
|
+
- Place all imports at the top of the file, grouped in the following order: standard library imports, third-party imports, local application imports. Separate each group with a blank line.
|
10
|
+
- Limit all lines to a maximum of 120 characters.
|
11
|
+
- Prefer single quotes for strings unless the string contains a single quote, in which case use double quotes.
|
12
|
+
- Use blank lines to separate functions, class definitions, and logical sections within functions.
|
13
|
+
- Use type hints for function arguments and return values where possible.
|
14
|
+
- Use docstrings to document functions that are used in the main python script, but not elsewhere.
|
15
|
+
- Avoid using bare except clauses; always specify the exception being caught.
|
16
|
+
- Use list comprehensions and generator expressions where appropriate for clarity and conciseness.
|
@@ -0,0 +1,22 @@
|
|
1
|
+
---
|
2
|
+
applyTo: "**/*.ts,**/*.tsx"
|
3
|
+
---
|
4
|
+
|
5
|
+
Apply the [general coding guidelines](./style-general.instructions.md) to all code.
|
6
|
+
|
7
|
+
# General Project Guidelines
|
8
|
+
- Use yarn instead of npm whenever relevant.
|
9
|
+
- Prefer using `export default function` over exporting at the end of the file.
|
10
|
+
|
11
|
+
# TypeScript Guidelines
|
12
|
+
- Use TypeScript for all new code
|
13
|
+
- Follow functional programming principles where possible
|
14
|
+
- Use interfaces for data structures prefixed with I like `interface IRecord`
|
15
|
+
- Prefer immutable data (const, readonly)
|
16
|
+
- Use optional chaining (?.) and nullish coalescing (??) operators
|
17
|
+
|
18
|
+
# React Guidelines
|
19
|
+
- Use functional components with hooks
|
20
|
+
- Follow the React hooks rules (no conditional hooks)
|
21
|
+
- Prefer one component per file
|
22
|
+
- Use Tailwindcss for styling
|
@@ -1,60 +1,11 @@
|
|
1
|
+
---
|
2
|
+
mode: 'agent'
|
3
|
+
tools: ['codebase', 'fetch']
|
4
|
+
description: 'Handle changing inputs for a biolib app, by adding, removing or modifying inputs in the config.yml and the python script.'
|
5
|
+
---
|
6
|
+
|
1
7
|
# Main task
|
2
8
|
Your task is to make sure that all inputs are handled correctly in the give Python script and/or biolib config file.
|
3
|
-
|
4
|
-
Inputs
|
5
|
-
|
6
|
-
# Syntax of config.yml
|
7
|
-
The file config.yml contains the information needed to render and run an application on BioLib. This configuration defines the entry to your application and what input arguments the user can set. When you edit an application using the graphical interface on BioLib the config.yml file is automatically updated.
|
8
|
-
|
9
|
-
The config file and python script specify how input options and settings will be rendered to the user of the application, and how inputs will be parsed. The input field should follow this structure:
|
10
|
-
|
11
|
-
```
|
12
|
-
arguments:
|
13
|
-
- key: --data # required
|
14
|
-
description: 'Input Dropdown' # required
|
15
|
-
key_value_separator: ' ' # optional, default is ' '
|
16
|
-
default_value: '' # optional, default is ''
|
17
|
-
type: dropdown # required
|
18
|
-
options:
|
19
|
-
'This will be shown as option one': 'value1'
|
20
|
-
'This will be shown as option two': 'value2'
|
21
|
-
required: true # optional, default is true
|
22
|
-
```
|
23
|
-
|
24
|
-
Under `type` you have the following options:
|
25
|
-
|
26
|
-
* `text` provides a text input field
|
27
|
-
* `file` provides a file select where users can upload an input file
|
28
|
-
* `text-file` provides both a text input field and a file select allowing the user supply either
|
29
|
-
* `sequence` like text-file, with checks for valid FASTA input characters
|
30
|
-
* `hidden` allows the application creator to provide a default input argument without it being shown to the end-user
|
31
|
-
* `toggle` provides a toggle switch where users can choose two options. Note that the options need to be named 'on' : 'value1' and 'off': 'value2'
|
32
|
-
* `number` provides a number input field
|
33
|
-
* `radio` provides a "radio select" where users can select one amongst a number of prespecified options
|
34
|
-
* `dropdown` provides a dropdown menu where users can select one amongst a number of prespecified options
|
35
|
-
* `multiselect` provides a dropdown menu where users can select one or more prespecified options
|
36
|
-
|
37
|
-
`sub_arguments`: Allow you to specify arguments that are only rendered if a user chooses a particular option in the parent argument. For example, an application might allow the user to run one of two commands, where each of these commands would need different input arguments:
|
38
|
-
|
39
|
-
```
|
40
|
-
arguments:
|
41
|
-
- key: --function
|
42
|
-
description: 'Choose a function'
|
43
|
-
key_value_separator: ''
|
44
|
-
default_value: ''
|
45
|
-
type: dropdown
|
46
|
-
options:
|
47
|
-
'Command A': a
|
48
|
-
'Command B': b
|
49
|
-
sub_arguments:
|
50
|
-
a:
|
51
|
-
- key: --argument_a
|
52
|
-
description: "Argument A takes a file input"
|
53
|
-
type: file
|
54
|
-
b:
|
55
|
-
- key: --argument_b
|
56
|
-
description: 'Argument B takes a text input'
|
57
|
-
type: text
|
58
|
-
```
|
59
|
-
|
60
|
-
Inputs in the Python script should be parsed with argparse, and should also enshrine the same requirements and defaults such that use is identical between the frontend and Python.
|
9
|
+
Read the documentation [here](https://biolib.com/docs/building-applications/syntax-of-config-yml/) to understand how the inputs are handled in the config.yml file.
|
10
|
+
Inputs in the Python script should be parsed with argparse. If a default is given in the config.yml file, it it is not necessary to set a default in the Python script.
|
11
|
+
Otherwise, the two files should be consistent.
|
@@ -1,302 +1,12 @@
|
|
1
|
-
|
2
|
-
|
3
|
-
|
4
|
-
|
5
|
-
|
6
|
-
|
7
|
-
|
8
|
-
|
9
|
-
|
10
|
-
biolib.
|
11
|
-
|
12
|
-
|
13
|
-
Alternatively, you can use an API token and set it as the `BIOLIB_TOKEN` environment variable. If the user requests this, direct them [here](https://biolib.com/settings/api-tokens/).
|
14
|
-
|
15
|
-
## Run using .cli()
|
16
|
-
|
17
|
-
To load an application into your Python script, add the following:
|
18
|
-
|
19
|
-
```python
|
20
|
-
import biolib
|
21
|
-
app = biolib.load('author/application')
|
22
|
-
```
|
23
|
-
|
24
|
-
To run an application call the function `.cli()` on the application you loaded above. For instance, to run samtools with the `--help` command:
|
25
|
-
|
26
|
-
```python
|
27
|
-
import biolib
|
28
|
-
|
29
|
-
samtools = biolib.load('samtools/samtools')
|
30
|
-
job = samtools.cli(args='--help')
|
31
|
-
print(job.get_stdout().decode())
|
32
|
-
```
|
33
|
-
|
34
|
-
Running an application returns a job object, which allows you to monitor progress and save results.
|
35
|
-
|
36
|
-
## Non blocking
|
37
|
-
|
38
|
-
By default, calling the function `.cli()` blocks until the application is finished. You can pass the keyword argument `blocking=False` to return immediately. For example the code below will print "in_progress":
|
39
|
-
|
40
|
-
```python
|
41
|
-
import biolib
|
42
|
-
|
43
|
-
samtools = biolib.load('samtools/samtools')
|
44
|
-
job = samtools.cli(args='--help', blocking=False)
|
45
|
-
print(job.get_status())
|
46
|
-
```
|
47
|
-
|
48
|
-
## Result prefix
|
49
|
-
|
50
|
-
You can annotate the result with a custom name when calling `.cli()` using the keyword argument `result_prefix` as:
|
51
|
-
|
52
|
-
```python
|
53
|
-
import biolib
|
54
|
-
|
55
|
-
samtools = biolib.load('samtools/samtools')
|
56
|
-
job = samtools.cli(args='--help', result_prefix='my_help_test')
|
57
|
-
```
|
58
|
-
|
59
|
-
Setting the result prefix makes it easy to distinguish results from one another on the result page.
|
60
|
-
|
61
|
-
## Run using .run()
|
62
|
-
|
63
|
-
The `.run()` function is a more Pythonic way to run applications where all keyword arguments are passed to the application as command line arguments. This function blocks and waits until the application is finished.
|
64
|
-
|
65
|
-
```python
|
66
|
-
samtools = biolib.load('samtools/samtools')
|
67
|
-
job = samtools.run()
|
68
|
-
```
|
69
|
-
|
70
|
-
## Run using .start()
|
71
|
-
|
72
|
-
The `.start()` function is a more Pythonic way to run applications where all keyword arguments are passed to the application as command line arguments. This function returns immediately when the job is created.
|
73
|
-
|
74
|
-
```python
|
75
|
-
samtools = biolib.load('samtools/samtools')
|
76
|
-
job = samtools.start()
|
77
|
-
```
|
78
|
-
|
79
|
-
## Search
|
80
|
-
|
81
|
-
To search for applications on BioLib use the function `biolib.search()` which takes a search query as the first argument:
|
82
|
-
|
83
|
-
```python
|
84
|
-
app_list = biolib.search('samtools')
|
85
|
-
print(app_list)
|
86
|
-
```
|
87
|
-
|
88
|
-
Should print something like below:
|
89
|
-
|
90
|
-
```
|
91
|
-
['samtools/samtools',
|
92
|
-
'samtools/samtools-fixmate',
|
93
|
-
'samtools/samtools-stats',
|
94
|
-
'samtools/samtools-collate',
|
95
|
-
'samtools/samtools-fastq',
|
96
|
-
...]
|
97
|
-
```
|
98
|
-
|
99
|
-
To run a specific application you can pass a value from the list above to `biolib.load()` and then call `app.cli()`:
|
100
|
-
|
101
|
-
```python
|
102
|
-
app = biolib.load(app_list[0])
|
103
|
-
job = app.cli('--help')
|
104
|
-
```
|
105
|
-
|
106
|
-
## Results
|
107
|
-
|
108
|
-
When a job has completed, its outputs can be accessed by the following functions:
|
109
|
-
|
110
|
-
```python
|
111
|
-
job.wait() # Wait until done
|
112
|
-
job.get_stdout() # Returns stdout as bytes
|
113
|
-
job.get_stderr() # Returns stderr as bytes
|
114
|
-
job.get_exit_code() # Returns exit code of the application as an integer
|
115
|
-
```
|
116
|
-
|
117
|
-
## Save files to disk
|
118
|
-
|
119
|
-
To save the output files to a local directory like "result_files" run:
|
120
|
-
|
121
|
-
```python
|
122
|
-
job.save_files(output_dir='result_files')
|
123
|
-
```
|
124
|
-
|
125
|
-
The `.save_files()` function also takes an optional `path_filter` argument as a glob pattern. For example to save all `.pdb` files from a result you can run:
|
126
|
-
|
127
|
-
```python
|
128
|
-
job.save_files(output_dir='result_files', path_filter='*.pdb')
|
129
|
-
```
|
130
|
-
|
131
|
-
## In memory files
|
132
|
-
|
133
|
-
Work with result files without saving them to disk. To list the output files from a job:
|
134
|
-
|
135
|
-
```python
|
136
|
-
job.list_output_files()
|
137
|
-
```
|
138
|
-
|
139
|
-
To load a single file into memory, without saving it to disk, run:
|
140
|
-
|
141
|
-
```python
|
142
|
-
my_csv_file = job.get_output_file('/my_file.csv')
|
143
|
-
```
|
144
|
-
|
145
|
-
To pass an output file to a library like Pandas or BioPython, run `.get_file_handle()` on the object:
|
146
|
-
|
147
|
-
```python
|
148
|
-
import pandas as pd
|
149
|
-
my_dataframe = pd.read_csv(my_csv_file.get_file_handle())
|
150
|
-
```
|
151
|
-
|
152
|
-
## Jobs
|
153
|
-
|
154
|
-
A job object refers to a specific run of an application. It holds progress information of the application run and the result when the job has completed.
|
155
|
-
|
156
|
-
### List jobs
|
157
|
-
|
158
|
-
When signed in, you can print a table of your jobs by running:
|
159
|
-
|
160
|
-
```python
|
161
|
-
biolib.show_jobs(count=25)
|
162
|
-
```
|
163
|
-
|
164
|
-
where count refers to the number of jobs you want to show.
|
165
|
-
|
166
|
-
### Retrieve a job
|
167
|
-
|
168
|
-
To retrieve a Job in python call `biolib.get_job()` with the Job's ID.
|
169
|
-
|
170
|
-
```python
|
171
|
-
job = biolib.get_job(job_id)
|
172
|
-
print(job.get_status())
|
173
|
-
```
|
174
|
-
|
175
|
-
You can use this to determine if a job has completed or is still in progress.
|
176
|
-
|
177
|
-
### Open in browser
|
178
|
-
|
179
|
-
You can open the job in your web browser to view the graphical and interactive output files.
|
180
|
-
|
181
|
-
```python
|
182
|
-
job.open_browser()
|
183
|
-
```
|
184
|
-
|
185
|
-
### Stream output
|
186
|
-
|
187
|
-
If your Job is still running you can attach to its stdout and stderr by running:
|
188
|
-
|
189
|
-
```python
|
190
|
-
job.stream_logs()
|
191
|
-
```
|
192
|
-
|
193
|
-
This will print current output and keep streaming stdout and stderr until the job has finished.
|
194
|
-
|
195
|
-
### Download output files
|
196
|
-
|
197
|
-
You can download job output files using the job ID. The job ID can be found under "Details" on the Results page, or in the share link:
|
198
|
-
|
199
|
-
```python
|
200
|
-
job_id = '1a234567-b89...'
|
201
|
-
job = biolib.get_job(job_id)
|
202
|
-
job.save_files('job_output/')
|
203
|
-
```
|
204
|
-
|
205
|
-
### Download input files
|
206
|
-
|
207
|
-
To download the input files of a job:
|
208
|
-
|
209
|
-
```python
|
210
|
-
job_id = '1a234567-b89...'
|
211
|
-
job = biolib.get_job(job_id)
|
212
|
-
job.save_input_files(output_dir='input_files')
|
213
|
-
```
|
214
|
-
|
215
|
-
## Start jobs in parallel
|
216
|
-
|
217
|
-
Use the `blocking=False` argument to `.cli()` on an application to get the job immediately without having to wait for the application to finish.
|
218
|
-
|
219
|
-
This feature allows for parallelized workflows as the one below:
|
220
|
-
|
221
|
-
```python
|
222
|
-
samtools = biolib.load('samtools/samtools')
|
223
|
-
my_fasta_files = ['seq1.fasta', 'seq2.fasta']
|
224
|
-
|
225
|
-
my_jobs = []
|
226
|
-
for file in my_fasta_files:
|
227
|
-
job = samtools.cli(file, blocking=False)
|
228
|
-
my_jobs.append(job)
|
229
|
-
```
|
230
|
-
|
231
|
-
## Experiments
|
232
|
-
|
233
|
-
An Experiment is a collection of jobs that you can retrieve together. To group the jobs in an Experiment use the following syntax:
|
234
|
-
|
235
|
-
```python
|
236
|
-
with biolib.Experiment('my-experiment-name'):
|
237
|
-
my_application.cli(input_1) # these two jobs will be
|
238
|
-
my_application.cli(input_2) # grouped in the same Experiment
|
239
|
-
```
|
240
|
-
|
241
|
-
All jobs started under the with statement will be grouped under the Experiment's ID (in this case `my-experiment-name`).
|
242
|
-
|
243
|
-
### List experiments
|
244
|
-
|
245
|
-
When logged in, you can print a table of your experiments by running:
|
246
|
-
|
247
|
-
```python
|
248
|
-
biolib.show_experiments(count=10)
|
249
|
-
```
|
250
|
-
|
251
|
-
where count refers to the number of experiments you want to show.
|
252
|
-
|
253
|
-
### Retrieve an experiment
|
254
|
-
|
255
|
-
To load an Experiment in Python, run the following:
|
256
|
-
|
257
|
-
```python
|
258
|
-
my_experiment = biolib.get_experiment('my-experiment-name')
|
259
|
-
print(my_experiment)
|
260
|
-
```
|
261
|
-
|
262
|
-
### Wait for all jobs
|
263
|
-
|
264
|
-
To block and wait until all jobs of an experiment have finished, use the `.wait()` function:
|
265
|
-
|
266
|
-
```python
|
267
|
-
my_experiment.wait()
|
268
|
-
```
|
269
|
-
|
270
|
-
### Retrieve jobs
|
271
|
-
|
272
|
-
To get a list of the Job objects contained in an Experiment, run:
|
273
|
-
|
274
|
-
```python
|
275
|
-
my_jobs = my_experiment.get_jobs()
|
276
|
-
for job in my_jobs:
|
277
|
-
# Print output
|
278
|
-
if job.get_status() == 'completed':
|
279
|
-
print(job.get_stdout())
|
280
|
-
else:
|
281
|
-
job.stream_logs()
|
282
|
-
|
283
|
-
# Save output files
|
284
|
-
job.save_files('my_results')
|
285
|
-
```
|
286
|
-
|
287
|
-
### List jobs in an Experiment
|
288
|
-
|
289
|
-
To show an overview of the jobs in your experiment run:
|
290
|
-
|
291
|
-
```python
|
292
|
-
my_experiment.show_jobs()
|
293
|
-
```
|
294
|
-
|
295
|
-
This prints a table of the jobs contained in your experiment.
|
296
|
-
|
297
|
-
### Mount files
|
298
|
-
|
299
|
-
Using `.mount_files()` you can mount all jobs of the experiment and their output files to a local directory. This allows you to explore all the files in the experiment using your file browser.
|
300
|
-
|
301
|
-
```python
|
302
|
-
my_experiment.mount_files(mount_path='my_local_directory')
|
1
|
+
---
|
2
|
+
mode: 'agent'
|
3
|
+
tools: ['githubRepo', 'codebase', 'fetch']
|
4
|
+
description: 'Handle running biolib apps, including login, running apps, and managing jobs and results.'
|
5
|
+
---
|
6
|
+
|
7
|
+
# Main task
|
8
|
+
Your task is to run one or more biolib apps, using the biolib Python API. You can find general instructions [here](https://biolib.com/docs/using-applications/python/)
|
9
|
+
A few relevant notes:
|
10
|
+
- You will be running this from inside a biolib app, so login is not necessary.
|
11
|
+
- Always look at the relevant app's #githubRepo. Ask the user for the repo, and inform them that it needs to be in the format `author/app_name`.
|
12
|
+
- If you do look at the repo, look at the config.yml to see how it expects inputs to be formatted.
|
@@ -14,10 +14,12 @@ biolib/_internal/lfs/__init__.py,sha256=gSWo_xg61UniYgD7yNYxeT4I9uaXBCBSi3_nmZjn
|
|
14
14
|
biolib/_internal/lfs/cache.py,sha256=pQS2np21rdJ6I3DpoOutnzPHpLOZgUIS8TMltUJk_k4,2226
|
15
15
|
biolib/_internal/libs/__init__.py,sha256=Jdf4tNPqe_oIIf6zYml6TiqhL_02Vyqwge6IELrAFhw,98
|
16
16
|
biolib/_internal/libs/fusepy/__init__.py,sha256=AWDzNFS-XV_5yKb0Qx7kggIhPzq1nj_BZS5y2Nso08k,41944
|
17
|
-
biolib/_internal/llm_instructions/.github/instructions/
|
18
|
-
biolib/_internal/llm_instructions/.github/instructions/
|
19
|
-
biolib/_internal/llm_instructions/.github/
|
20
|
-
biolib/_internal/llm_instructions/.github/
|
17
|
+
biolib/_internal/llm_instructions/.github/instructions/general-app-knowledge.instructions.md,sha256=-j8v0GRtDhHoqP2wcGUykiwU7HQ0DmkCNxw_01oKMdY,546
|
18
|
+
biolib/_internal/llm_instructions/.github/instructions/style-general.instructions.md,sha256=tl2Ve1ZPlPBrH6CSrjIkiMA8xnM2tQIJs1cerKCyAkU,761
|
19
|
+
biolib/_internal/llm_instructions/.github/instructions/style-python.instructions.md,sha256=xfypuPqMsz5ejobDoVI0HjmNqksl16aFuIol1nAhpHg,1034
|
20
|
+
biolib/_internal/llm_instructions/.github/instructions/style-react-ts.instructions.md,sha256=GQoRL-bfPwwNIW4W0yN_guVIqFNVCG2_7adOCaxiz-w,755
|
21
|
+
biolib/_internal/llm_instructions/.github/prompts/biolib_app_inputs.prompt.md,sha256=SMzXZImdID0yKjhE1fG54VrHdD8IVuwRxRKsMF-KjWs,697
|
22
|
+
biolib/_internal/llm_instructions/.github/prompts/biolib_run_apps.prompt.md,sha256=-t1bmGr3zEFa6lKHaLcI98yq4Sg1TCMW8xbelNSHaOA,696
|
21
23
|
biolib/_internal/llm_instructions/__init__.py,sha256=47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU,0
|
22
24
|
biolib/_internal/push_application.py,sha256=I7yHGcwK6udc2hVmOQIc1BcQBipAMibEjURMI6HgdXk,12502
|
23
25
|
biolib/_internal/runtime.py,sha256=BiHl4klUHr36MCpqKaUso4idHeBZfPAahLYRQrabFqA,486
|
@@ -131,8 +133,8 @@ biolib/utils/cache_state.py,sha256=u256F37QSRIVwqKlbnCyzAX4EMI-kl6Dwu6qwj-Qmag,3
|
|
131
133
|
biolib/utils/multipart_uploader.py,sha256=XvGP1I8tQuKhAH-QugPRoEsCi9qvbRk-DVBs5PNwwJo,8452
|
132
134
|
biolib/utils/seq_util.py,sha256=Ozk0blGtPur_D9MwShD02r_mphyQmgZkx-lOHOwnlIM,6730
|
133
135
|
biolib/utils/zip/remote_zip.py,sha256=0wErYlxir5921agfFeV1xVjf29l9VNgGQvNlWOlj2Yc,23232
|
134
|
-
pybiolib-1.2.
|
135
|
-
pybiolib-1.2.
|
136
|
-
pybiolib-1.2.
|
137
|
-
pybiolib-1.2.
|
138
|
-
pybiolib-1.2.
|
136
|
+
pybiolib-1.2.814.dist-info/LICENSE,sha256=F2h7gf8i0agDIeWoBPXDMYScvQOz02pAWkKhTGOHaaw,1067
|
137
|
+
pybiolib-1.2.814.dist-info/METADATA,sha256=dkiANMd2NxMszfRSRvCAlAxPS-3Eas0SQAdzGs_8yOc,1570
|
138
|
+
pybiolib-1.2.814.dist-info/WHEEL,sha256=b4K_helf-jlQoXBBETfwnf4B04YC67LOev0jo4fX5m8,88
|
139
|
+
pybiolib-1.2.814.dist-info/entry_points.txt,sha256=p6DyaP_2kctxegTX23WBznnrDi4mz6gx04O5uKtRDXg,42
|
140
|
+
pybiolib-1.2.814.dist-info/RECORD,,
|
@@ -1,13 +0,0 @@
|
|
1
|
-
---
|
2
|
-
applyTo: '**'
|
3
|
-
---
|
4
|
-
|
5
|
-
Variable names are allowed to be verbose, and should be descriptive.
|
6
|
-
|
7
|
-
Code comments should only be added for complex logic or unintuitive code that is not adequately explained by the function names themselves.
|
8
|
-
|
9
|
-
Unit tests are not necessary. Tests should instead be written as simple examples demonstrating the functionality of relevant functions.
|
10
|
-
|
11
|
-
Always use 4 spaces for indentation.
|
12
|
-
|
13
|
-
Function definitions should be typed as specifically as possible.
|
@@ -1,9 +0,0 @@
|
|
1
|
-
---
|
2
|
-
applyTo: '**'
|
3
|
-
---
|
4
|
-
|
5
|
-
Use yarn instead of npm whenever relevant.
|
6
|
-
|
7
|
-
When running BioLib Apps, use [this file](../prompts/biolib_run_apps.prompt.md) as context to understand how that works.
|
8
|
-
|
9
|
-
When working with BioLib App inputs, use [this file](../prompts/biolib_app_inputs.prompt.md) as context to understand how the different files should be connected and formatted.
|
File without changes
|
File without changes
|
File without changes
|