Re: Should we consider project basenames unique?

[Ben Cooksley]

On Thu, Nov 25, 2021 at 1:20 AM  wrote:

> > I have no idea why this is all of a sudden a problem for Arch Linux.
>
> In makepkg we do not have origin with project path (see comments in
> pkgbuild linked in
> https://invent.kde.org/sdk/releaseme/-/merge_requests/13). We have
> directory path to which the project was cloned, and it may (and man not) be
> named as project name. In pkgbuild I want to download and build
> translations for project, for that I use KDE_L10N_SYNC_TRANSLATIONS=ON. And
> then cmake module wants to call fetchpo.rb from releaseme. And as it was
> unable to detect project path (because origin is local path, not matching
> regex to extract it), it fallbacks to cmake project name:
> https://invent.kde.org/frameworks/extra-cmake-modules/-/blob/9f519983d628c7c2a68ee1a8dc7a1cbb83c8f535/kde-modules/KDECMakeSettings.cmake#L321.
> And currently fetchpo.rb fails to determine the project by that.
>

I see. It sounds like the basename of the folder is not even guaranteed
based on the above statement, in which case it wouldn't even matter if the
repository names themselves were unique (instead of just our identifier for
them) as your distribution tooling would potentially discard them.

Given you are wanting to include translations, it sounds like the real fix
is something we discussed in a meeting at some point where scripty would
maintain a copy of the latest translations for a project in the actual
project repository.
I think that was being tested in one of our repositories but not sure on
the status of this.


> I wanted to get rid of that function, and use directly cmake project name
> https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/199#note_339860.
> Then modification of releaseme is required (that I created mr 13 for). Can
> we use cmake_project_name as project identifiers? If yes, then I see it is
> no problem to add a from_identifier() to releaseme::project. And then the
> problem will be solved.
>
>
Cheers,
Ben


> 24.11.2021, 13:02, "Ben Cooksley" :
>
> On Wed, Nov 24, 2021 at 10:28 PM Harald Sitter  wrote:
>
> On Wed, Nov 24, 2021 at 10:02 AM Ben Cooksley  wrote:
> > Which means you either provide the path (plasma-mobile/plasma-dialer) or
> you need to go look in the metadata anyway.
>
> If names are unique (not persistent, just unique) and plasma-dialer is
> what I want to release then I know plasma-dialer is called
> plasma-dialer because I'm a plasma-dialer dev. I can then call
> releasme with the argument  'plasma-dialer' and releaseme can work out
> the path from that because the name is global unique so there is only
> one plasma-dialer and that will be what I want to release.
>
>
> In the specific case of releaseme for 99% of projects the situation you've
> described is true, so what you are talking about is a non-issue.
> There are only a small handful of projects where identifier != repository
> name, and the developers in charge of those projects should be able to
> handle that and be aware of the difference - usually because they requested
> it.
>
> I have no idea why this is all of a sudden a problem for Arch Linux.
>
>
> HS
>
>
> Regards,
> Ben
>
>

Re: Should we consider project basenames unique?

[ashark]

> I have no idea why this is all of a sudden a problem for Arch Linux.In makepkg we do not have origin with project path (see comments in pkgbuild linked in https://invent.kde.org/sdk/releaseme/-/merge_requests/13). We have directory path to which the project was cloned, and it may (and man not) be named as project name. In pkgbuild I want to download and build translations for project, for that I use KDE_L10N_SYNC_TRANSLATIONS=ON. And then cmake module wants to call fetchpo.rb from releaseme. And as it was unable to detect project path (because origin is local path, not matching regex to extract it), it fallbacks to cmake project name: https://invent.kde.org/frameworks/extra-cmake-modules/-/blob/9f519983d628c7c2a68ee1a8dc7a1cbb83c8f535/kde-modules/KDECMakeSettings.cmake#L321. And currently fetchpo.rb fails to determine the project by that. I wanted to get rid of that function, and use directly cmake project name https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/199#note_339860. Then modification of releaseme is required (that I created mr 13 for). Can we use cmake_project_name as project identifiers? If yes, then I see it is no problem to add a from_identifier() to releaseme::project. And then the problem will be solved.24.11.2021, 13:02, "Ben Cooksley" :On Wed, Nov 24, 2021 at 10:28 PM Harald Sitter  wrote:On Wed, Nov 24, 2021 at 10:02 AM Ben Cooksley  wrote:
> Which means you either provide the path (plasma-mobile/plasma-dialer) or you need to go look in the metadata anyway.

If names are unique (not persistent, just unique) and plasma-dialer is
what I want to release then I know plasma-dialer is called
plasma-dialer because I'm a plasma-dialer dev. I can then call
releasme with the argument  'plasma-dialer' and releaseme can work out
the path from that because the name is global unique so there is only
one plasma-dialer and that will be what I want to release.In the specific case of releaseme for 99% of projects the situation you've described is true, so what you are talking about is a non-issue.There are only a small handful of projects where identifier != repository name, and the developers in charge of those projects should be able to handle that and be aware of the difference - usually because they requested it.I have no idea why this is all of a sudden a problem for Arch Linux.

HSRegards,Ben

Re: Should we consider project basenames unique?

[Ben Cooksley]

On Wed, Nov 24, 2021 at 10:28 PM Harald Sitter  wrote:

> On Wed, Nov 24, 2021 at 10:02 AM Ben Cooksley  wrote:
> > Which means you either provide the path (plasma-mobile/plasma-dialer) or
> you need to go look in the metadata anyway.
>
> If names are unique (not persistent, just unique) and plasma-dialer is
> what I want to release then I know plasma-dialer is called
> plasma-dialer because I'm a plasma-dialer dev. I can then call
> releasme with the argument  'plasma-dialer' and releaseme can work out
> the path from that because the name is global unique so there is only
> one plasma-dialer and that will be what I want to release.
>

In the specific case of releaseme for 99% of projects the situation you've
described is true, so what you are talking about is a non-issue.
There are only a small handful of projects where identifier != repository
name, and the developers in charge of those projects should be able to
handle that and be aware of the difference - usually because they requested
it.

I have no idea why this is all of a sudden a problem for Arch Linux.


> HS
>

Regards,
Ben

Re: Should we consider project basenames unique?

[Harald Sitter]

On Wed, Nov 24, 2021 at 10:02 AM Ben Cooksley  wrote:
> Which means you either provide the path (plasma-mobile/plasma-dialer) or you 
> need to go look in the metadata anyway.

If names are unique (not persistent, just unique) and plasma-dialer is
what I want to release then I know plasma-dialer is called
plasma-dialer because I'm a plasma-dialer dev. I can then call
releasme with the argument  'plasma-dialer' and releaseme can work out
the path from that because the name is global unique so there is only
one plasma-dialer and that will be what I want to release.

HS

Re: Should we consider project basenames unique?

[Ben Cooksley]

On Wed, Nov 24, 2021 at 9:46 PM Harald Sitter  wrote:

> On Wed, Nov 24, 2021 at 6:00 AM Ben Cooksley  wrote:
> >
> > On Wed, Nov 24, 2021 at 2:29 PM Aleix Pol  wrote:
> >>
> >> On Wed, Nov 24, 2021 at 2:10 AM ash...@linuxcomp.ru <
> ash...@linuxcomp.ru> wrote:
> >> >
> >> > Hello.
> >> > There is currently a problem that projects are identified by path in
> invent.kde.org. But in pkgbuilds in Arch Linux the makepkg clones repo
> twice, first time to the dir with pkgbuild, and second time to the srcdir
> for build package. And that second repo has first repo as origin, i.e. its
> origin is path to the first repo. And this leads to breakage of determining
> project identifier in cmake module. To workaround, I either need to clone
> to the path that matches the regexp, such as crutch.kde.org:pim/zanshin.git
> or fixing the origin of the problem.
> >> >
> >> > I wanted to fix it by identifying the project by its name. See
> https://invent.kde.org/sdk/releaseme/-/merge_requests/13.
> >> >
> >> > Now, the question is, could we consider project names unique? In that
> case, we can merge my mr, and path crutch will not be needed anymore.
> >>
> >> I agree it would be a problem to have different repositories with the
> >> same name. I'm not sure how we can enforce it though.
> >
> >
> > This is something that Sysadmin already encountered and resolved.
> >
> > Please see the 'identifier' key in the repository metadata (located at
> https://invent.kde.org/sysadmin/repo-metadata/ in the projects/
> subfolder) which we guarantee to be unique.
> > This is already used and relied upon by scripty as well as our internal
> systems (such as commits.kde.org) when referencing repositories.
>
> That is the problem. We, the humans, do not know the identifier nor
> should we care. When I want to make a release of plasma-dialer I
> should be able to pass plasma-dialer as argument because I know the
> repo/project is called plasma-dialer.
>

Sorry i'm not seeing your point here.

First, there is a fairly small group of projects where the identifier does
not equal the repository name. Those projects have good valid reasons (as
outlined below) for that difference.

Second, regardless of what you pass to releaseme, it still has to locate
the project on invent.kde.org, which means it needs to know the group it is
in - otherwise it cannot clone the repository.
Which means you either provide the path (plasma-mobile/plasma-dialer) or
you need to go look in the metadata anyway.

If you have an existing checkout then you shouldn't need to provide an
argument because releaseme should be able to infer it for you from the URL
in .git/config of the clone - and can make reference to the metadata (it is
an automated tool after all)


> > The repository name itself (stripped of any folders) is not guaranteed
> to be unique.
>
> That is what is proposed to get changed.
>

The whole reason why we went with identifiers is because we already had
requests from people in certain namespaces (maui/ in particular, but others
as well if memory serves) who were agitating about their repositories being
prefixed with the overall project name due to the extremely generic names
of their repositories.

Those prefixes also read very strange when taking into account the group
name. If this change were to go through, then you end up with URLs such as
https://invent.kde.org/maui/maui-pix - compared with what we have currently
which is https://invent.kde.org/maui/pix


> HS
>

Regards,
Ben

Re: Should we consider project basenames unique?

[Harald Sitter]

On Wed, Nov 24, 2021 at 6:00 AM Ben Cooksley  wrote:
>
> On Wed, Nov 24, 2021 at 2:29 PM Aleix Pol  wrote:
>>
>> On Wed, Nov 24, 2021 at 2:10 AM ash...@linuxcomp.ru  
>> wrote:
>> >
>> > Hello.
>> > There is currently a problem that projects are identified by path in 
>> > invent.kde.org. But in pkgbuilds in Arch Linux the makepkg clones repo 
>> > twice, first time to the dir with pkgbuild, and second time to the srcdir 
>> > for build package. And that second repo has first repo as origin, i.e. its 
>> > origin is path to the first repo. And this leads to breakage of 
>> > determining project identifier in cmake module. To workaround, I either 
>> > need to clone to the path that matches the regexp, such as 
>> > crutch.kde.org:pim/zanshin.git or fixing the origin of the problem.
>> >
>> > I wanted to fix it by identifying the project by its name. See 
>> > https://invent.kde.org/sdk/releaseme/-/merge_requests/13.
>> >
>> > Now, the question is, could we consider project names unique? In that 
>> > case, we can merge my mr, and path crutch will not be needed anymore.
>>
>> I agree it would be a problem to have different repositories with the
>> same name. I'm not sure how we can enforce it though.
>
>
> This is something that Sysadmin already encountered and resolved.
>
> Please see the 'identifier' key in the repository metadata (located at 
> https://invent.kde.org/sysadmin/repo-metadata/ in the projects/ subfolder) 
> which we guarantee to be unique.
> This is already used and relied upon by scripty as well as our internal 
> systems (such as commits.kde.org) when referencing repositories.

That is the problem. We, the humans, do not know the identifier nor
should we care. When I want to make a release of plasma-dialer I
should be able to pass plasma-dialer as argument because I know the
repo/project is called plasma-dialer.

> The repository name itself (stripped of any folders) is not guaranteed to be 
> unique.

That is what is proposed to get changed.

HS

Re: Should we consider project basenames unique?

[Ben Cooksley]

On Wed, Nov 24, 2021 at 2:29 PM Aleix Pol  wrote:

> On Wed, Nov 24, 2021 at 2:10 AM ash...@linuxcomp.ru 
> wrote:
> >
> > Hello.
> > There is currently a problem that projects are identified by path in
> invent.kde.org. But in pkgbuilds in Arch Linux the makepkg clones repo
> twice, first time to the dir with pkgbuild, and second time to the srcdir
> for build package. And that second repo has first repo as origin, i.e. its
> origin is path to the first repo. And this leads to breakage of determining
> project identifier in cmake module. To workaround, I either need to clone
> to the path that matches the regexp, such as crutch.kde.org:pim/zanshin.git
> or fixing the origin of the problem.
> >
> > I wanted to fix it by identifying the project by its name. See
> https://invent.kde.org/sdk/releaseme/-/merge_requests/13.
> >
> > Now, the question is, could we consider project names unique? In that
> case, we can merge my mr, and path crutch will not be needed anymore.
>
> I agree it would be a problem to have different repositories with the
> same name. I'm not sure how we can enforce it though.
>

This is something that Sysadmin already encountered and resolved.

Please see the 'identifier' key in the repository metadata (located at
https://invent.kde.org/sysadmin/repo-metadata/ in the projects/ subfolder)
which we guarantee to be unique.
This is already used and relied upon by scripty as well as our internal
systems (such as commits.kde.org) when referencing repositories.

The repository name itself (stripped of any folders) is not guaranteed to
be unique.


> Aleix
>

Cheers,
Ben

Re: Should we consider project basenames unique?

[Aleix Pol]

On Wed, Nov 24, 2021 at 2:10 AM ash...@linuxcomp.ru  wrote:
>
> Hello.
> There is currently a problem that projects are identified by path in 
> invent.kde.org. But in pkgbuilds in Arch Linux the makepkg clones repo twice, 
> first time to the dir with pkgbuild, and second time to the srcdir for build 
> package. And that second repo has first repo as origin, i.e. its origin is 
> path to the first repo. And this leads to breakage of determining project 
> identifier in cmake module. To workaround, I either need to clone to the path 
> that matches the regexp, such as crutch.kde.org:pim/zanshin.git or fixing the 
> origin of the problem.
>
> I wanted to fix it by identifying the project by its name. See 
> https://invent.kde.org/sdk/releaseme/-/merge_requests/13.
>
> Now, the question is, could we consider project names unique? In that case, 
> we can merge my mr, and path crutch will not be needed anymore.

I agree it would be a problem to have different repositories with the
same name. I'm not sure how we can enforce it though.

Aleix

Should we consider project basenames unique?

[ash...@linuxcomp.ru]

Hello.There is currently a problem that projects are identified by path in invent.kde.org. But in pkgbuilds in Arch Linux the makepkg clones repo twice, first time to the dir with pkgbuild, and second time to the srcdir for build package. And that second repo has first repo as origin, i.e. its origin is path to the first repo. And this leads to breakage of determining project identifier in cmake module. To workaround, I either need to clone to the path that matches the regexp, such as crutch.kde.org:pim/zanshin.git or fixing the origin of the problem.I wanted to fix it by identifying the project by its name. See https://invent.kde.org/sdk/releaseme/-/merge_requests/13.Now, the question is, could we consider project names unique? In that case, we can merge my mr, and path crutch will not be needed anymore.