Add option to turn off adding of empty __init__.py files
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 3/5
- Temps estimé
- 1-2 jours
- Accessibilité débutants
- 35/100
- Type d'issue
- Fonctionnalité
- Clarté
- Plutôt claire
- Activité
- À l'abandon
- Stack technique
- python
- Domaine
- build-system, tooling
Piste de recherche
L’issue ne nomme ni fichier ni test ; commencez par localiser le point d’entrée de génération de code Python de la bibliothèque principale ainsi que le code qui crée des fichiers init.py vides. Comparez le comportement demandé à l’option legacy_create_init=False de Bazel, puis vérifiez que les chemins de paquets d’espace de noms générés fonctionnent sans ces fichiers et que le comportement par défaut reste inchangé.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Summary
Improve compatibility in monorepo/Bazel usages, so that package path can be treated as native namespace packages
What is the feature request for?
The core library
The Problem
When using two proto files that have a similar prefix such as a.b.c and a.b.d, when these are produced as two separate artifacts consuming both of these as libraries would cause a import path collision since they both share __init__.py files in a and a/b folders.
The Ideal Solution
Add an option to skip creation of empty __init__.py files. Build tools treat the folders without __init__.py as namespace packages.
The Current Solution
I made the change as a patch and applied the patch on the library to get this capability.
I can roll the change up as a PR if there's interest in this.
Related Solution
A similar option called legacy_create_init=False was introduced on bazel to solve this exact issue with package names. See https://rules-proto-grpc.com/en/latest/lang/python.html#python-grpc-compile:~:text=legacy_create_init%3DFalse .
- Langage dominant
- Python
- Étoiles
- 1.8k
- Forks
- 236
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Propose un modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de danielgtaylor/python-betterproto
-
Difficulté 3/5 1-2 jours Accessibilité débutants 55/100
-
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 15/100
-
bug investigation needed
Difficulté 3/5 1-2 jours Accessibilité débutants 42/100
-
bug investigation needed
Difficulté 3/5 1-2 jours Accessibilité débutants 45/100
-
bug investigation needed
Difficulté 4/5 3-5 jours Accessibilité débutants 38/100
danielgtaylor/python-betterproto#676 · 3 commentaires ·
Toutes les issues de danielgtaylor/python-betterproto
Issues similaires
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 69/100
jejjohnson/gaussx#752 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 85/100
521xueweihan/HelloGitHub#4270 ·
-
enhancement owner: den-haag
Difficulté 2/5 1-3 heures Accessibilité débutants 67/100
Les mainteneurs répondent en général sous 6 jours
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
ok-oldking/ok-wuthering-waves#1828 ·
Les mainteneurs répondent en général sous 1 jour
-
lesson-submission pending-review
Difficulté 1/5 Moins d'une heure Accessibilité débutants 65/100
Ikalus1988/MisakaNet#4512 ·
Les mainteneurs répondent en général sous 1 jour