[FR] Improve Ability to detect if App has been Initialized
Mantenedores costumam responder em até 1 dia
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 35/100
Direção de pesquisa
Comece lendo firebase_admin/init.py, especialmente initialize_app() e get_app() nas proximidades das linhas vinculadas. Compare a função is_initialized proposta e as abordagens de erros específicos e, em seguida, determine qual comportamento público os maintainers desejam. O trabalho estará concluído quando os usuários puderem detectar de forma confiável se o app solicitado está inicializado sem inspecionar a variável privada _apps ou analisar um ValueError genérico.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
Is your feature request related to a problem? Please describe.
Currently there is not a way offered by the library to check if firebase_admin.initialize_app(...)(source) has been called and an app has been initialized besides catching an exception. This can result in library users seeing the following exception:
ValueError: The default Firebase app already exists. This means you called initialize_app() more than once without providing an app name as the second argument. In most cases you only need to call initialize_app() once. But if you do want to initialize multiple apps, pass a second argument to initialize_app() to give each app a unique name.
source
From the discussion in this Stackoverflow post, there are two main approaches library users have implemented:
1. use a try/except block on ValueError to get the app and initialize it if there is an exception
try:
app = firebase_admin.get_app()
except ValueError as e:
cred = credentials.Certificate(CREDENTIALS_FIREBASE_PATH)
firebase_admin.initialize_app(cred)
Pros: simple
Cons: ValueError is a general error so theoretically the use does not know for sure the error is regarding initialization, so further inspection is needed to verify that the error is related to app initialization, e.g. a string check on "already exists".
2. check the "private" _apps variable
if not firebase_admin._apps:
cred = credentials.Certificate('path/to/serviceAccountKey.json')
default_app = firebase_admin.initialize_app(cred)
Pros: not relying on try/except flow
Cons: accessing a "private" variable, as the library owners now if you change this variable it will cause breaking changes for many library users.
Describe the solution you'd like
Option 1: Implement a function like is_initialized(name=_DEFAULT_APP_NAME)
This could check _apps for the given name and return true / false for whether it is initialized.
Option 2: Raise a specific error
Implement a new error that extends ValueError for backwards compatibility and raise the error with this new type.
For example:
class AppInitializedError(ValueError):
def __init__(self, message):
super().__init__(message)
This could then be used:
try:
app = firebase_admin.get_app()
except AppInitializedError:
cred = credentials.Certificate(CREDENTIALS_FIREBASE_PATH)
firebase_admin.initialize_app(cred)
These implementations could be done in conjunction, however option 1 is safest as it only adds new behavior and changes no existing behavior. Furthermore there will still be those against using try / except as the "expected" way to check if the app is initialized as offered in option 2.
Describe alternatives you've considered
The alternatives are described in the stackoverflow post above (link) as well as in this issue.
- Linguagem predominante
- Python
- Estrelas
- 1.2k
- Forks
- 362
- Merge médio
- 8h 7min
- PRs com merge (30d)
- 3
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Tem um modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de firebase/firebase-admin-python
-
api: remoteconfig
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
firebase/firebase-admin-python#957 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
api: database type: feature request
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 62/100
firebase/firebase-admin-python#58 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 45/100
firebase/firebase-admin-python#978 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
[FR] Support VERIFY_AND_CHANGE_EMAIL in generate_email_action_link (parity with firebase-admin-node)Talvez livre de novo @lahirumaramba assumiu há 151 dias e não há nenhum pull request aberto. Abertaapi: auth
firebase/firebase-admin-python#949 · 2 comentários · 1 reação · 1 responsável ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 43/100
firebase/firebase-admin-python#945 · 1 comentário · 1 reação ·
Mantenedores costumam responder em até 1 dia
Todas as issues de firebase/firebase-admin-python
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
mikf/gallery-dl#9791 ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 88/100
fossasia/eventyay#6151 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
P4: low tooling
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 88/100
jeffknupp/association#318 ·
-
azure-cost bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
microsoft/GitHub-Copilot-for-Azure#3330 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 74/100
raullenchai/Rapid-MLX#4097 ·
Mantenedores costumam responder em até 1 dia