Hey, is there a way to rename the repository that is created by a

Definition

object? Like with using the

@repository

decorator? In the source code I can see it gets a default value of

name=SINGLETON_REPOSITORY_NAME

Can we override it somehow or is this only possible using the decorator?

just write my_name=Definitions(...) then my_name shows up

hmm I put it in my

repo.py

file and in dagit it is shown as

repo.py

hmm your right

E.g. lets say I have multiple gRPC servers running (different Teams) and contributing to one Dagit instance. How will the naming of each created repository be decided?

Hi Timo - the

repo.py

you're describing is actually the name of the code location, not the repository. That name is configurable - what are you using to tell dagit which code locations to load? If it's a workspace.yaml file then there's a location_name key that you can use

oh ok, the location_name key I wasn’t aware of… Thanks, I’ll try that….

no problem - You can see an example with location_name set here: https://docs.dagster.io/concepts/code-locations/workspace-files#initializing-the-server

although this takes away the flexibility to use python for dynamic namings. For e.g. we append the current version of our build

@repository(
    name=f'data_platform_repo_v{get_current_version()}_{STACK}',

same for Description. Is it possible for you guys to add this to your roadmap to include name and description arguments to Definition?

Is this something you could file a feature request for? I don't think we actually display the description for repositories in dagit either currently

Sure where do I do that? 🙂

Yeah feature requests are tracked here: https://github.com/dagster-io/dagster/issues

@Timo Klockow keep in mind that you can keep on using

@repository

for this purpose. Additionally in the next dot release there is a function in

dagster._core.definitions.definitions_class

called

create_repository_using_definitions_args

that will allow you create a named repository using the definitions arguments

Alright, thank you Nick 😊

However I do think it is worth stepping back and figuring out how to best support your use case. It definitely feels like you are hacking around a feature we lack (e.g. tags or metadata on code locations).

Plus I believe

description

is nowhere shown in Dagit