aigency 0.0.1.dev20250904075757__py3-none-any.whl → 0.0.1rc225507851__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.
- aigency-0.0.1rc225507851.dist-info/METADATA +267 -0
- {aigency-0.0.1.dev20250904075757.dist-info → aigency-0.0.1rc225507851.dist-info}/RECORD +4 -4
- aigency-0.0.1.dev20250904075757.dist-info/METADATA +0 -267
- {aigency-0.0.1.dev20250904075757.dist-info → aigency-0.0.1rc225507851.dist-info}/WHEEL +0 -0
- {aigency-0.0.1.dev20250904075757.dist-info → aigency-0.0.1rc225507851.dist-info}/top_level.txt +0 -0
@@ -0,0 +1,267 @@
|
|
1
|
+
Metadata-Version: 2.4
|
2
|
+
Name: aigency
|
3
|
+
Version: 0.0.1rc225507851
|
4
|
+
Summary: Add your description here
|
5
|
+
Requires-Python: >=3.12
|
6
|
+
Description-Content-Type: text/markdown
|
7
|
+
Requires-Dist: google-adk>=1.11.0
|
8
|
+
Requires-Dist: a2a-sdk==0.3.0
|
9
|
+
Requires-Dist: litellm<1.73.0,>=1.72.6
|
10
|
+
Requires-Dist: pyyaml==6.0.2
|
11
|
+
Requires-Dist: PyJWT==2.10.1
|
12
|
+
|
13
|
+
# aigency-lib
|
14
|
+
|
15
|
+
A library for creating and managing AI agents.
|
16
|
+
|
17
|
+
## Quick Start
|
18
|
+
|
19
|
+
To test a simple agent:
|
20
|
+
|
21
|
+
```bash
|
22
|
+
cd examples/simple_agents/hello_world_agent
|
23
|
+
docker compose up
|
24
|
+
```
|
25
|
+
|
26
|
+
## 🔧 Version Management
|
27
|
+
|
28
|
+
This project includes an automated system for managing versions in both development and production.
|
29
|
+
|
30
|
+
### Version Manager
|
31
|
+
|
32
|
+
The `scripts/version_manager.py` script helps you manage your package versions locally.
|
33
|
+
|
34
|
+
#### Available Commands
|
35
|
+
|
36
|
+
##### 1. View current information
|
37
|
+
```bash
|
38
|
+
python scripts/version_manager.py show
|
39
|
+
```
|
40
|
+
**What it does:**
|
41
|
+
- Shows the current version in `pyproject.toml`
|
42
|
+
- Shows the current git branch
|
43
|
+
- Shows the current commit
|
44
|
+
- If you're not on `main`, suggests a development version
|
45
|
+
|
46
|
+
**Example output:**
|
47
|
+
```
|
48
|
+
Current version: 0.0.1
|
49
|
+
Branch: feature/new-agent
|
50
|
+
Commit: a1b2c3d
|
51
|
+
Suggested dev version: 0.0.1.dev20250409143022+feature/new-agent.a1b2c3d
|
52
|
+
```
|
53
|
+
|
54
|
+
##### 2. Create development version
|
55
|
+
```bash
|
56
|
+
python scripts/version_manager.py dev
|
57
|
+
```
|
58
|
+
**What it does:**
|
59
|
+
- Takes the current version and creates a development version
|
60
|
+
- Format: `version.devYYYYMMDDHHMMSS+branch.commit`
|
61
|
+
- Automatically updates the `pyproject.toml`
|
62
|
+
|
63
|
+
**Example:**
|
64
|
+
```bash
|
65
|
+
# If you're on branch "feature/auth" with commit "abc123"
|
66
|
+
python scripts/version_manager.py dev
|
67
|
+
# Result: 0.0.1.dev20250409143022
|
68
|
+
```
|
69
|
+
|
70
|
+
##### 3. Set specific version
|
71
|
+
```bash
|
72
|
+
python scripts/version_manager.py set --version "0.1.0"
|
73
|
+
```
|
74
|
+
**What it does:**
|
75
|
+
- Changes the version to the one you specify
|
76
|
+
- Useful for releases or to fix versions
|
77
|
+
|
78
|
+
**Examples:**
|
79
|
+
```bash
|
80
|
+
# Release version
|
81
|
+
python scripts/version_manager.py set --version "1.0.0"
|
82
|
+
|
83
|
+
# Beta version
|
84
|
+
python scripts/version_manager.py set --version "1.0.0b1"
|
85
|
+
|
86
|
+
# Alpha version
|
87
|
+
python scripts/version_manager.py set --version "1.0.0a1"
|
88
|
+
```
|
89
|
+
|
90
|
+
##### 4. Create Release Candidate version
|
91
|
+
```bash
|
92
|
+
python scripts/version_manager.py rc --version "1.0.1"
|
93
|
+
```
|
94
|
+
**What it does:**
|
95
|
+
- Creates an RC version with the format `version-rc<commit>`
|
96
|
+
- Useful for preparing releases on `release/*` branches
|
97
|
+
|
98
|
+
##### 5. Validate current version
|
99
|
+
```bash
|
100
|
+
python scripts/version_manager.py validate
|
101
|
+
```
|
102
|
+
**What it does:**
|
103
|
+
- Validates that the current version is appropriate for the branch
|
104
|
+
- Verifies semantic format on `main` and `release/*` branches
|
105
|
+
|
106
|
+
##### 6. Create dev with custom base version
|
107
|
+
```bash
|
108
|
+
python scripts/version_manager.py dev --base-version "0.2.0"
|
109
|
+
```
|
110
|
+
**What it does:**
|
111
|
+
- Uses a different base version than the current one
|
112
|
+
- Useful when you want to prepare a dev version for the next release
|
113
|
+
|
114
|
+
### 🚀 Recommended Workflow
|
115
|
+
|
116
|
+
#### For daily development:
|
117
|
+
```bash
|
118
|
+
# 1. View current status
|
119
|
+
python scripts/version_manager.py show
|
120
|
+
|
121
|
+
# 2. If you're on a feature branch, create dev version
|
122
|
+
python scripts/version_manager.py dev
|
123
|
+
|
124
|
+
# 3. Make your changes and commits
|
125
|
+
git add .
|
126
|
+
git commit -m "feat: new functionality"
|
127
|
+
|
128
|
+
# 4. If you need to update the dev version (optional)
|
129
|
+
python scripts/version_manager.py dev
|
130
|
+
```
|
131
|
+
|
132
|
+
#### For releases:
|
133
|
+
```bash
|
134
|
+
# 1. On main branch, set release version
|
135
|
+
python scripts/version_manager.py set --version "1.0.0"
|
136
|
+
|
137
|
+
# 2. Commit the version
|
138
|
+
git add pyproject.toml
|
139
|
+
git commit -m "bump: version 1.0.0"
|
140
|
+
|
141
|
+
# 3. Use GitHub workflow to publish
|
142
|
+
```
|
143
|
+
|
144
|
+
#### For testing:
|
145
|
+
```bash
|
146
|
+
# Create specific test version
|
147
|
+
python scripts/version_manager.py set --version "1.0.0rc1"
|
148
|
+
```
|
149
|
+
|
150
|
+
### ⚠️ PyPI Limitations
|
151
|
+
|
152
|
+
PyPI doesn't allow "local versions" (versions with `+` and local identifiers). That's why we've adapted the format:
|
153
|
+
|
154
|
+
- ❌ Not allowed: `1.0.0.dev20250409+feature.abc123`
|
155
|
+
- ✅ Allowed: `1.0.0.dev20250409`
|
156
|
+
|
157
|
+
**Solution for Release Candidates:**
|
158
|
+
- We convert the commit hash (hexadecimal) to decimal
|
159
|
+
- Example: commit `abc123` → `11256099` → version `1.0.1rc11256099`
|
160
|
+
- This maintains commit uniqueness in a PyPI-compatible format
|
161
|
+
|
162
|
+
**Result:**
|
163
|
+
- Dev versions include unique timestamp
|
164
|
+
- RC versions include commit hash (in decimal)
|
165
|
+
- We maintain traceability without using local versions
|
166
|
+
|
167
|
+
### 📋 Practical Use Cases
|
168
|
+
|
169
|
+
**Scenario 1: Working on a feature**
|
170
|
+
```bash
|
171
|
+
git checkout -b feature/new-auth
|
172
|
+
python scripts/version_manager.py dev
|
173
|
+
# Now you have: 0.0.1.dev20250409143022
|
174
|
+
```
|
175
|
+
|
176
|
+
**Scenario 2: Preparing release**
|
177
|
+
```bash
|
178
|
+
git checkout main
|
179
|
+
python scripts/version_manager.py set --version "1.0.0"
|
180
|
+
git add pyproject.toml
|
181
|
+
git commit -m "release: v1.0.0"
|
182
|
+
```
|
183
|
+
|
184
|
+
**Scenario 3: Preparing Release Candidate**
|
185
|
+
```bash
|
186
|
+
git checkout -b release/1.0.1
|
187
|
+
python scripts/version_manager.py rc --version "1.0.1"
|
188
|
+
# Result: 1.0.1rc12345678 (where 12345678 is the commit hash in decimal)
|
189
|
+
```
|
190
|
+
|
191
|
+
**Scenario 4: Urgent hotfix**
|
192
|
+
```bash
|
193
|
+
git checkout -b hotfix/critical-bug
|
194
|
+
python scripts/version_manager.py dev --base-version "1.0.1"
|
195
|
+
# Result: 1.0.1.dev20250409143022
|
196
|
+
```
|
197
|
+
|
198
|
+
## 🔄 Intelligent CI/CD Workflow
|
199
|
+
|
200
|
+
The project includes a single intelligent workflow (`python-publish.yml`) that automatically handles different version types based on the branch:
|
201
|
+
|
202
|
+
### Automatic behavior by branch:
|
203
|
+
|
204
|
+
#### 🚀 `main` Branch - Production Versions
|
205
|
+
- **Trigger**: Push to `main` or manual execution
|
206
|
+
- **Version**: Uses exactly the version from `pyproject.toml`
|
207
|
+
- **Validations**:
|
208
|
+
- ✅ Verifies it's a valid semantic version (e.g.: `1.0.0`)
|
209
|
+
- ✅ Verifies it doesn't already exist on PyPI
|
210
|
+
- ❌ Fails if it contains development suffixes (`dev`, `rc`, `alpha`, `beta`)
|
211
|
+
- **Target**: PyPI production
|
212
|
+
|
213
|
+
#### 🎯 `release/*` Branches - Release Candidates
|
214
|
+
- **Trigger**: Push to `release/X.Y.Z` branch or manual execution
|
215
|
+
- **Version**: `X.Y.ZrcN` where N is the commit hash in decimal (e.g.: `1.0.1rc12345678`)
|
216
|
+
- **Validations**:
|
217
|
+
- ✅ Verifies that `X.Y.Z` is a valid semantic version
|
218
|
+
- ✅ Extracts version from branch name
|
219
|
+
- ✅ Uses commit hash as unique identifier
|
220
|
+
- ✅ PyPI-compatible format
|
221
|
+
- **Target**: PyPI production
|
222
|
+
- **Example**: Branch `release/1.0.1` + commit `abc123` → Version `1.0.1rc11256099`
|
223
|
+
|
224
|
+
#### 🔧 Other Branches - Development Versions
|
225
|
+
- **Trigger**: Push to any other branch or manual execution
|
226
|
+
- **Version**: `current.devYYYYMMDDHHMMSS` (e.g.: `0.0.1.dev20250409143022`)
|
227
|
+
- **Target**: PyPI production
|
228
|
+
- **Note**: No local versions for PyPI compatibility
|
229
|
+
|
230
|
+
### Recommended workflow:
|
231
|
+
|
232
|
+
```bash
|
233
|
+
# 1. Development on feature branch
|
234
|
+
git checkout -b feature/new-functionality
|
235
|
+
# Automatic version: 0.0.1.dev20250409143022+feature-new-functionality.abc123
|
236
|
+
|
237
|
+
# 2. Prepare release
|
238
|
+
git checkout -b release/1.0.0
|
239
|
+
git push origin release/1.0.0
|
240
|
+
# Automatic version: 1.0.0rc12345678
|
241
|
+
|
242
|
+
# 3. Final release
|
243
|
+
git checkout main
|
244
|
+
python scripts/version_manager.py set --version "1.0.0"
|
245
|
+
git add pyproject.toml
|
246
|
+
git commit -m "release: v1.0.0"
|
247
|
+
git push origin main
|
248
|
+
# Version: 1.0.0 (with validations)
|
249
|
+
```
|
250
|
+
|
251
|
+
## 📦 Installation
|
252
|
+
|
253
|
+
```bash
|
254
|
+
pip install aigency
|
255
|
+
```
|
256
|
+
|
257
|
+
## 🛠️ Development
|
258
|
+
|
259
|
+
1. Clone the repository
|
260
|
+
2. Install development dependencies
|
261
|
+
3. Use the version manager to manage versions during development
|
262
|
+
|
263
|
+
```bash
|
264
|
+
git clone <repo-url>
|
265
|
+
cd aigency-lib
|
266
|
+
pip install -e .
|
267
|
+
```
|
@@ -9,7 +9,7 @@ aigency/utils/config_service.py,sha256=ql2NsQBjhwH6phbsbqp698je1NmAUlZuyXOE0Bb9L
|
|
9
9
|
aigency/utils/logger.py,sha256=NYvEknt2BeSqn484ivaLFwP0KbAtBxDXFoJiiKiXKeI,3796
|
10
10
|
aigency/utils/singleton.py,sha256=u5stRwgwiXRt6b2vTX4W8zuchWvQ9kbcvztQDceaF3E,313
|
11
11
|
aigency/utils/utils.py,sha256=1eA-RxMZW6QIxhrK9TbxysxwKhGiJqjrvOk69xR-zKo,2698
|
12
|
-
aigency-0.0.
|
13
|
-
aigency-0.0.
|
14
|
-
aigency-0.0.
|
15
|
-
aigency-0.0.
|
12
|
+
aigency-0.0.1rc225507851.dist-info/METADATA,sha256=ZG4oKDTI1SDA02JiBQzizH0PCMr7Df9OjjxnSTM2WJI,7170
|
13
|
+
aigency-0.0.1rc225507851.dist-info/WHEEL,sha256=_zCd3N1l69ArxyTb8rzEoP9TpbYXkqRFSNOD5OuxnTs,91
|
14
|
+
aigency-0.0.1rc225507851.dist-info/top_level.txt,sha256=nr33Htucgjs3wJFNugPV8w7b9ZgSnytxCtRiinR3eb8,8
|
15
|
+
aigency-0.0.1rc225507851.dist-info/RECORD,,
|
@@ -1,267 +0,0 @@
|
|
1
|
-
Metadata-Version: 2.4
|
2
|
-
Name: aigency
|
3
|
-
Version: 0.0.1.dev20250904075757
|
4
|
-
Summary: Add your description here
|
5
|
-
Requires-Python: >=3.12
|
6
|
-
Description-Content-Type: text/markdown
|
7
|
-
Requires-Dist: google-adk>=1.11.0
|
8
|
-
Requires-Dist: a2a-sdk==0.3.0
|
9
|
-
Requires-Dist: litellm<1.73.0,>=1.72.6
|
10
|
-
Requires-Dist: pyyaml==6.0.2
|
11
|
-
Requires-Dist: PyJWT==2.10.1
|
12
|
-
|
13
|
-
# aigency-lib
|
14
|
-
|
15
|
-
Una librería para crear y gestionar agentes de IA.
|
16
|
-
|
17
|
-
## Inicio rápido
|
18
|
-
|
19
|
-
Para probar un agente simple:
|
20
|
-
|
21
|
-
```bash
|
22
|
-
cd examples/simple_agents/hello_world_agent
|
23
|
-
docker compose up
|
24
|
-
```
|
25
|
-
|
26
|
-
## 🔧 Gestión de versiones
|
27
|
-
|
28
|
-
Este proyecto incluye un sistema automatizado para gestionar versiones tanto en desarrollo como en producción.
|
29
|
-
|
30
|
-
### Version Manager
|
31
|
-
|
32
|
-
El script `scripts/version_manager.py` te ayuda a gestionar las versiones de tu paquete de forma local.
|
33
|
-
|
34
|
-
#### Comandos disponibles
|
35
|
-
|
36
|
-
##### 1. Ver información actual
|
37
|
-
```bash
|
38
|
-
python scripts/version_manager.py show
|
39
|
-
```
|
40
|
-
**Qué hace:**
|
41
|
-
- Muestra la versión actual en `pyproject.toml`
|
42
|
-
- Muestra la rama git actual
|
43
|
-
- Muestra el commit actual
|
44
|
-
- Si no estás en `main`, sugiere una versión de desarrollo
|
45
|
-
|
46
|
-
**Ejemplo de salida:**
|
47
|
-
```
|
48
|
-
Versión actual: 0.0.1
|
49
|
-
Rama: feature/new-agent
|
50
|
-
Commit: a1b2c3d
|
51
|
-
Versión dev sugerida: 0.0.1.dev20250409143022+feature/new-agent.a1b2c3d
|
52
|
-
```
|
53
|
-
|
54
|
-
##### 2. Crear versión de desarrollo
|
55
|
-
```bash
|
56
|
-
python scripts/version_manager.py dev
|
57
|
-
```
|
58
|
-
**Qué hace:**
|
59
|
-
- Toma la versión actual y crea una versión de desarrollo
|
60
|
-
- Formato: `version.devYYYYMMDDHHMMSS+branch.commit`
|
61
|
-
- Actualiza automáticamente el `pyproject.toml`
|
62
|
-
|
63
|
-
**Ejemplo:**
|
64
|
-
```bash
|
65
|
-
# Si estás en rama "feature/auth" con commit "abc123"
|
66
|
-
python scripts/version_manager.py dev
|
67
|
-
# Resultado: 0.0.1.dev20250409143022
|
68
|
-
```
|
69
|
-
|
70
|
-
##### 3. Establecer versión específica
|
71
|
-
```bash
|
72
|
-
python scripts/version_manager.py set --version "0.1.0"
|
73
|
-
```
|
74
|
-
**Qué hace:**
|
75
|
-
- Cambia la versión a la que especifiques
|
76
|
-
- Útil para releases o para corregir versiones
|
77
|
-
|
78
|
-
**Ejemplos:**
|
79
|
-
```bash
|
80
|
-
# Versión de release
|
81
|
-
python scripts/version_manager.py set --version "1.0.0"
|
82
|
-
|
83
|
-
# Versión beta
|
84
|
-
python scripts/version_manager.py set --version "1.0.0b1"
|
85
|
-
|
86
|
-
# Versión alpha
|
87
|
-
python scripts/version_manager.py set --version "1.0.0a1"
|
88
|
-
```
|
89
|
-
|
90
|
-
##### 4. Crear versión Release Candidate
|
91
|
-
```bash
|
92
|
-
python scripts/version_manager.py rc --version "1.0.1"
|
93
|
-
```
|
94
|
-
**Qué hace:**
|
95
|
-
- Crea una versión RC con el formato `version-rc<commit>`
|
96
|
-
- Útil para preparar releases en ramas `release/*`
|
97
|
-
|
98
|
-
##### 5. Validar versión actual
|
99
|
-
```bash
|
100
|
-
python scripts/version_manager.py validate
|
101
|
-
```
|
102
|
-
**Qué hace:**
|
103
|
-
- Valida que la versión actual sea apropiada para la rama
|
104
|
-
- Verifica formato semántico en `main` y ramas `release/*`
|
105
|
-
|
106
|
-
##### 6. Crear dev con versión base personalizada
|
107
|
-
```bash
|
108
|
-
python scripts/version_manager.py dev --base-version "0.2.0"
|
109
|
-
```
|
110
|
-
**Qué hace:**
|
111
|
-
- Usa una versión base diferente a la actual
|
112
|
-
- Útil cuando quieres preparar una dev version para la próxima release
|
113
|
-
|
114
|
-
### 🚀 Flujo de trabajo recomendado
|
115
|
-
|
116
|
-
#### Para desarrollo diario:
|
117
|
-
```bash
|
118
|
-
# 1. Ver estado actual
|
119
|
-
python scripts/version_manager.py show
|
120
|
-
|
121
|
-
# 2. Si estás en una rama feature, crear versión dev
|
122
|
-
python scripts/version_manager.py dev
|
123
|
-
|
124
|
-
# 3. Hacer tus cambios y commits
|
125
|
-
git add .
|
126
|
-
git commit -m "feat: nueva funcionalidad"
|
127
|
-
|
128
|
-
# 4. Si necesitas actualizar la versión dev (opcional)
|
129
|
-
python scripts/version_manager.py dev
|
130
|
-
```
|
131
|
-
|
132
|
-
#### Para releases:
|
133
|
-
```bash
|
134
|
-
# 1. En rama main, establecer versión de release
|
135
|
-
python scripts/version_manager.py set --version "1.0.0"
|
136
|
-
|
137
|
-
# 2. Commit de la versión
|
138
|
-
git add pyproject.toml
|
139
|
-
git commit -m "bump: version 1.0.0"
|
140
|
-
|
141
|
-
# 3. Usar el workflow de GitHub para publicar
|
142
|
-
```
|
143
|
-
|
144
|
-
#### Para testing:
|
145
|
-
```bash
|
146
|
-
# Crear versión de test específica
|
147
|
-
python scripts/version_manager.py set --version "1.0.0rc1"
|
148
|
-
```
|
149
|
-
|
150
|
-
### ⚠️ Limitaciones de PyPI
|
151
|
-
|
152
|
-
PyPI no permite "local versions" (versiones con `+` y identificadores locales). Por eso, hemos adaptado el formato:
|
153
|
-
|
154
|
-
- ❌ No permitido: `1.0.0.dev20250409+feature.abc123`
|
155
|
-
- ✅ Permitido: `1.0.0.dev20250409`
|
156
|
-
|
157
|
-
**Solución para Release Candidates:**
|
158
|
-
- Convertimos el hash del commit (hexadecimal) a decimal
|
159
|
-
- Ejemplo: commit `abc123` → `11256099` → versión `1.0.1rc11256099`
|
160
|
-
- Esto mantiene la unicidad del commit en un formato compatible con PyPI
|
161
|
-
|
162
|
-
**Resultado:**
|
163
|
-
- Las versiones dev incluyen timestamp único
|
164
|
-
- Las versiones RC incluyen el hash del commit (en decimal)
|
165
|
-
- Mantenemos trazabilidad sin usar local versions
|
166
|
-
|
167
|
-
### 📋 Casos de uso prácticos
|
168
|
-
|
169
|
-
**Escenario 1: Trabajando en una feature**
|
170
|
-
```bash
|
171
|
-
git checkout -b feature/new-auth
|
172
|
-
python scripts/version_manager.py dev
|
173
|
-
# Ahora tienes: 0.0.1.dev20250409143022
|
174
|
-
```
|
175
|
-
|
176
|
-
**Escenario 2: Preparando release**
|
177
|
-
```bash
|
178
|
-
git checkout main
|
179
|
-
python scripts/version_manager.py set --version "1.0.0"
|
180
|
-
git add pyproject.toml
|
181
|
-
git commit -m "release: v1.0.0"
|
182
|
-
```
|
183
|
-
|
184
|
-
**Escenario 3: Preparando Release Candidate**
|
185
|
-
```bash
|
186
|
-
git checkout -b release/1.0.1
|
187
|
-
python scripts/version_manager.py rc --version "1.0.1"
|
188
|
-
# Resultado: 1.0.1rc12345678 (donde 12345678 es el hash del commit en decimal)
|
189
|
-
```
|
190
|
-
|
191
|
-
**Escenario 4: Hotfix urgente**
|
192
|
-
```bash
|
193
|
-
git checkout -b hotfix/critical-bug
|
194
|
-
python scripts/version_manager.py dev --base-version "1.0.1"
|
195
|
-
# Resultado: 1.0.1.dev20250409143022
|
196
|
-
```
|
197
|
-
|
198
|
-
## 🔄 Workflow de CI/CD Inteligente
|
199
|
-
|
200
|
-
El proyecto incluye un único workflow inteligente (`python-publish.yml`) que maneja automáticamente diferentes tipos de versiones según la rama:
|
201
|
-
|
202
|
-
### Comportamiento automático por rama:
|
203
|
-
|
204
|
-
#### 🚀 Rama `main` - Versiones de Producción
|
205
|
-
- **Trigger**: Push a `main` o ejecución manual
|
206
|
-
- **Versión**: Usa exactamente la versión del `pyproject.toml`
|
207
|
-
- **Validaciones**:
|
208
|
-
- ✅ Verifica que sea una versión semántica válida (ej: `1.0.0`)
|
209
|
-
- ✅ Verifica que no exista ya en PyPI
|
210
|
-
- ❌ Falla si contiene sufijos de desarrollo (`dev`, `rc`, `alpha`, `beta`)
|
211
|
-
- **Destino**: PyPI producción
|
212
|
-
|
213
|
-
#### 🎯 Ramas `release/*` - Release Candidates
|
214
|
-
- **Trigger**: Push a rama `release/X.Y.Z` o ejecución manual
|
215
|
-
- **Versión**: `X.Y.ZrcN` donde N es el hash del commit en decimal (ej: `1.0.1rc12345678`)
|
216
|
-
- **Validaciones**:
|
217
|
-
- ✅ Verifica que `X.Y.Z` sea una versión semántica válida
|
218
|
-
- ✅ Extrae la versión del nombre de la rama
|
219
|
-
- ✅ Usa hash del commit como identificador único
|
220
|
-
- ✅ Formato compatible con PyPI
|
221
|
-
- **Destino**: PyPI producción
|
222
|
-
- **Ejemplo**: Rama `release/1.0.1` + commit `abc123` → Versión `1.0.1rc11256099`
|
223
|
-
|
224
|
-
#### 🔧 Otras ramas - Versiones de Desarrollo
|
225
|
-
- **Trigger**: Push a cualquier otra rama o ejecución manual
|
226
|
-
- **Versión**: `current.devYYYYMMDDHHMMSS` (ej: `0.0.1.dev20250409143022`)
|
227
|
-
- **Destino**: PyPI producción
|
228
|
-
- **Nota**: Sin local versions para compatibilidad con PyPI
|
229
|
-
|
230
|
-
### Flujo de trabajo recomendado:
|
231
|
-
|
232
|
-
```bash
|
233
|
-
# 1. Desarrollo en feature branch
|
234
|
-
git checkout -b feature/new-functionality
|
235
|
-
# Versión automática: 0.0.1.dev20250409143022+feature-new-functionality.abc123
|
236
|
-
|
237
|
-
# 2. Preparar release
|
238
|
-
git checkout -b release/1.0.0
|
239
|
-
git push origin release/1.0.0
|
240
|
-
# Versión automática: 1.0.0rc12345678
|
241
|
-
|
242
|
-
# 3. Release final
|
243
|
-
git checkout main
|
244
|
-
python scripts/version_manager.py set --version "1.0.0"
|
245
|
-
git add pyproject.toml
|
246
|
-
git commit -m "release: v1.0.0"
|
247
|
-
git push origin main
|
248
|
-
# Versión: 1.0.0 (con validaciones)
|
249
|
-
```
|
250
|
-
|
251
|
-
## 📦 Instalación
|
252
|
-
|
253
|
-
```bash
|
254
|
-
pip install aigency
|
255
|
-
```
|
256
|
-
|
257
|
-
## 🛠️ Desarrollo
|
258
|
-
|
259
|
-
1. Clona el repositorio
|
260
|
-
2. Instala las dependencias de desarrollo
|
261
|
-
3. Usa el version manager para gestionar versiones durante el desarrollo
|
262
|
-
|
263
|
-
```bash
|
264
|
-
git clone <repo-url>
|
265
|
-
cd aigency-lib
|
266
|
-
pip install -e .
|
267
|
-
```
|
File without changes
|
{aigency-0.0.1.dev20250904075757.dist-info → aigency-0.0.1rc225507851.dist-info}/top_level.txt
RENAMED
File without changes
|