Repository: meltano/meltano

Issue:
revert: project-name in project_id
In https://github.com/meltano/meltano/pull/6621 we added the `project name` to the project_id on `init`. Even though we hash the id prior to sending, its addition was unnecessary and creates a few problems:

* having the project name in the id confuses the purpose of the id. We don't need to know or include the directory name in the project id and its inclusion sends the wrong signal that we do care about it somehow
* while it's true that `project_id` can be any string, we generally don't want to encourage folks to change it unless they have a strong reason to
* when trying to correlate local testing to events we're seeing through our production snowplow pipeline, having to hash the id is unnecessarily burdensome when we'd rather just look for the GUID itself

I would support a documentation update to make it clear that `project_id` can be any string but that it's generally not recommended to update if you don't need to.

Also, I did notice that as part of this update it seems like `project_id` gets put at the end of the file - is there anyway to bring that back up above the environments?

@WillDaSilva @aaronsteers 


Discussion:
> In https://github.com/meltano/meltano/pull/6621 we added the `project name` to the `project_id` on init.

It should be noted that prior to #6621 the default was for there to be no `project_id` on init.

> having the project name in the id confuses the purpose of the id. We don't need to know or include the directory name in the project id and its inclusion sends the wrong signal that we do care about it somehow

We don't care about its specific value, but the users probably prefer something readable. My [comment from Slack](https://meltano.slack.com/archives/C03GKHWS0HM/p1662645796144219?thread_ts=1662585209.438779&cid=C03GKHWS0HM) applies here:

> Some of the reasons I went with the `<project name>-<random UUID>` approach are for readability (random UUIDs are difficult to recognize), and also so that it was clear that the `project_id` field was not for a UUID - it supports any string identifier.

> while it's true that project_id can be any string, we generally don't want to encourage folks to change it unless they have a strong reason to

I don't see how the current handling encourages users to change the project ID.

> when trying to correlate local testing to events we're seeing through our production snowplow pipeline, having to hash the id is unnecessarily burdensome when we'd rather just look for the GUID itself

This seems like a fringe case. Does this happen with any sort of regularity? Why not just set the project ID to a UUID of your choosing, instead of sticking with the default generated from `meltano init`?

In any case, I have no strong feelings about what the default project ID should be. If you feel strongly about this, it's very easy for me to change the default.

---

> it seems like project_id gets put at the end of the file - is there anyway to bring that back up above the environments?

It can be done, but I don't know whether it can be done easily/cleanly. It may be more trouble than it's worth. @edgarrmondragon is there any way to control where `ProjectSettingsService.set` inserts a value in `meltano.yml`? If not, maybe we can just edit the YAML file directly using ruamel. Since we have a guarantee that the `meltano.yml` file as just created, my intuition is that that would be safe enough.

@tayloramurphy 
> is there any way to control where `ProjectSettingsService.set` inserts a value in `meltano.yml`? If not, maybe we can just edit the YAML file directly using ruamel. Since we have a guarantee that the `meltano.yml` file as just created, my intuition is that that would be safe enough.

@WillDaSilva it was discussed back in the ruamel PR: https://github.com/meltano/meltano/pull/6308#issuecomment-1176596663. There's a bit of complexity involved in enforcing a position for certain keys, but it's definitely doable.
Thanks @edgarrmondragon. In any case, that should be handled as a separate issue from the default project ID format. @tayloramurphy 
I'll pop a separate issue for the structure. Edit: Created https://github.com/meltano/meltano/issues/6734

> It should be noted that prior to https://github.com/meltano/meltano/pull/6621 the default was for there to be no project_id on init.

@WillDaSilva That's not accurate, unless you're saying it was removed in a particular version and then brought back in v2.5. I tested in v2.1 and this was my meltano.yml after init:

```yaml
version: 1
default_environment: dev
project_id: f58355da-fd1a-4ecf-920d-38cdc5267f0b
environments:
- name: dev
- name: staging
- name: prod
```

and in version 2.4 after init:

```yaml
version: 1
default_environment: dev
environments:
- name: dev
- name: staging
- name: prod
project_id: e3ebcf06-644d-475e-be4f-a3c5e0ba9a9e
```

I think that's where my confusion came from because my understanding was that there always was a project_id and in v2.5 we added the project name while fixing an additional bug. 
@tayloramurphy Sorry, I should've been more clear. I meant that the `meltano init` code did not create a project ID. Instead it got created by some telemetry code later on (but before the process exits) as a side effect. Having `meltano init` handle the creation of the initial project ID is preferable to relying on that side effect, particularly since that side effect stopped occurring when we removed the legacy telemetry code.

The default value was previously being created by the telemetry code as it still does now when no project ID is found in either `meltano.yml` or in `.meltano/analytics.json`.

As for why it was in the correct position, that's just because it was some of the first code I had written for the Meltano codebase, and I didn't know how to update `meltano.yml` properly yet. I did it in a rather buggy way that happened to keep `project_id` at the top - I'm a bit concerned that it passed review.


@WillDaSilva ah that makes sense then! Thanks for explaining 😄 

Resolving patch:
diff --git a/src/meltano/core/project_init_service.py b/src/meltano/core/project_init_service.py
--- a/src/meltano/core/project_init_service.py
+++ b/src/meltano/core/project_init_service.py
@@ -66,7 +66,7 @@ def init(self, activate: bool = True, add_discovery: bool = False) -> Project:
         self.settings_service = ProjectSettingsService(self.project)
         self.settings_service.set(
             "project_id",
-            f"{self.project_name}-{uuid.uuid4()}",
+            str(uuid.uuid4()),
             store=SettingValueStore.MELTANO_YML,
         )
         self.set_send_anonymous_usage_stats()


Test patch: