@marcusomnis hey there ! :) those particular URL formats are because of the namespace followed by Pagure so AFAIK the directory structure is :

repo -> has all the repositories in Pagure

repo/fork/<user> -> has all repository forked by that user

and I think we don't want two user to have repo with same name having said that I think @pingou and @puiterwijk can give you more on this . :smile:

@marcusomnis i read somewhere about this. The idea behind not namespacing a project under a user is that: The project belongs to a community and not an individual.

@marcusomnis i read somewhere about this. The idea behind not namespacing a project under a user is that: The project belongs to a community and not an individual.

I can understand that this might be useful in some circumstances, but it doesn't really look like a good solution in general.

1. if I want to setup Pagure for me and my friends, we don't have a "community", we just host our repos in the same instance
2. if I want to setup Pagure for a larger community, say for instance my school/uni/hackerspace, users still can't create new repos without conflicting with each-other. Many people for example could share their ".dotfiles" repositories
3. if I want to setup Pagure for my company, some repositories might be shared this way, but employees still can't make their own repositories with the name they want without conflicting with each-other
4. Git is distributed by design, meaning that each person/user is supposed to have their own copy. Having a central, shared repository looks more like SVN than Git...

In all these scenarios (and probably many more), either I have to maintain multiple instances of Pagure instead of just one, or tell people to namespace all their repos using some prefix. None of these are sensible solutions.

So, I understand your point, and I see the merits of this design. But overall I think the current URL scheme is worse than the simpler "/" solution.

@farhaan @vivekanand1101 Personally I don't understand why projects must belong to a community. Could any of you please explain the design behind this, and why did you take this choice? And also why you don't want to change it?

Just to give you one more example, assume that I want to make a new project, a calendar (maybe a JavaScript library, because I develop in JavaScript). I login to pagure.io, create my new repository calendar and push my code. Cool. Now let's say you are a C developer and you're working on a calendar module for your project, which is totally unrelated to my project. So, you also want to create a new repository called calendar for your module, but guess what? You can't! So, how do you call it? "c-calendar"? Maybe somebody else took it already. "my-project-calendar"? Let's hope no other project exist with the same name!
This is very weird, it's a global namespace for all projects which doesn't make sense.

I like Pagure, but I totally don't understand this decision for a global namespace. If any of you guys can tell me how two people can work on two unrelated projects with the same name, then it's fine for me and I won't argue anymore. The point is that right now Pagure URL schema is not "democratic", in the sense that either

• the projects' names are consumed in a "first-come-first-served" way, or
• the projects' names are decided by the instance admins, and users can only contribute to those by forking

To further prove my point take a look at my public profile page. As you can see I've created a bunch of new repos with the word "pagure" in them. For example "pagure-backup", "pagure-exporter", and "pagure-ci". And I didn't take "pagure" only because it's taken already, but maybe I can come up with some other good names. Good luck with that if you need any of those names! What are you gonna do now? Either go through the burden of choosing another name (and maybe ultimately come up with some very weird name because all other options are taken already), or force me to rename my projects. Or, is there a way for you to create a repo with the same name? On top of this there is a trust issue: if I'm a new user and I want to install pagure, I'll immediately assume that every repo called "pagure-*" is something official and maybe I'll install it. You don't see any problem with this?

Is this the direction that Pagure wants to take?!

I wouldn't have commented since pingou is coming back today and he is the one who can answer your queries best but, you seem frustrated by the fact that we didn't reply.

@marcusomnis first of all, chill. Myself and @farhaan have been here for only one year and this decision was taken long before that and i am sure @pingou (author of then Progit now Pagure) must have thought about this. I understand what you want to say and i see the advantages of namespacing as well. @pingou can correct me if i am wrong here but, pagure has been developed with pkgs.fedoraproject.org in mind, which hosts all the git repos of rpms and it doesn't have git collaboration as of now. There is no user namespacing there.

@pingou should tell you more on this. Thanks for showing so much interest in pagure though. But, you didn't have to create so many repos to make a point. :)

i actually came to this thread because i too would like to see this feature in pagure and to offer some encouragement and suggestions to the OP but after reading his last post i have had a change of heart

in case you guys have not looked, he is still squatting those names days after the point has been made along with others such as:

debian , fedora , pingou , ryanlerch , vivekanand1101

where i come from this is called a "dick move" - not a productive method of gaining favor for your opinion but an act of disrespect

so please do not ever implement this feature - although it is actually a strict requirement for our use case, i would prefer to implement it myself rather then to see such juvenile tactics be validated

So I have a few things to say on this ticket.

First of all, it took me a long time to reply because I got a little bit annoyed by the "demonstration" of @marcusomnis. There was clearly no need for such a childish behavior to open this discussion.
Seeing that @billauger was also saddened by this behavior helped (it wasn't just me).

That being said, @marcusomnis has been using an email provider that has been recently used mostly by spammer spamming the Fedora project in general. This has led to both of the accounts created by @marcusomnis to be blocked. This is unfortunate for two reasons:

• @marcusomnis can no longer contribute to this discussion unless they ask for the account to be unblocked
• @marcusomnis can no longer delete the projects created.

So I will be deleting all of @marcusomnis 's project directly in the DB, without trying to figure out if there were potential genuine projects in there.

That being said, regarding the topic at hand.

Pagure currently supported what we called fake-namespace it was basically that projects were allowed to have up to one / in their name. So you could create pingou/test if you wanted to.

In #1282 we move from these fake namespace to real one. There was originally the thought that fake namespace would be easier, but actually, the hardest part was done when implementing these fake namespaces so moving to actual namespace was actually quite straight forward.

This still does not entirely solve the problem at hand, especially since the namespace allowed are:

• specified in the configuration file
• a group that the user is a member of

So if someone wanted to group a bunch of project under a certain namespace, they could just create the corresponding group and place all their project under it.

That still doesn't entirely satisfies the question of: people wanting to publish their dotfiles repo. For this I have the idea of allowing to create personal project, which will be projects, stored under the user's namespace (so <user>/<project>) but where pull-requests will not be allowed.
The idea is that personal project aren't collaborative. If you wish to add someone to the project, that's fine, if someone wants to report issues, that's also fine (we could consider making issues off by default though). If you wish to build a community around it, then you'll need to make it an official project, not something personal.

I believe that with these two approaches we could support most if not all use-cases we want.

Does that make sense? More thoughts? Ideas?

how are existing projects affected by this? for example, this project is named 'pagure' - does that exclude the creation of a new group named 'pagure'? - could the existing 'pagure' project be transfered to some other group such as 'pagure-team/pagure' - would that then open a void in the namespace allowing then a 'pagure' group be created?

what about new repos? i would suggest that all new repos should be under some namespace so that a repo name like 'pagure' would not be allowed - the routing convention used by many other repo hosts (e.g. bitbucket, github, gitlab, gogs) is like:

https://host/group/              <-- group profile page
https://host/user/               <-- user profile page
https://host/group/settings      <-- group settings page
https://host/user/settings       <-- user settings page
https://host/group/group-repo-1  <-- group repo
https://host/group/group-repo-2  <-- group repo
https://host/user/user-repo-1    <-- user repo
https://host/user/user-repo-2    <-- user repo

without knowing how this was implemented it is not clear why would these personal repos need to be so limited - for example why would there be any difference between 'a-group/a-group-project' and 'a-user/a-project' - what if a team group be automatically created for each user with the username as the team name and that user automatically having full permissions to that group - so that 'a-user/' would be the name of a group with the 'a-user' user as the one initial member and all repos created by 'a-user' would fall under the 'a-user' namespace (group) by default

otherwise it sounds like "personal project" is describing a "private" project but pagure already support private projects - i can not see why anyone would need a project that is public but not collaborative - this would apparently be merely for distribution? in which case this person could just as well host a tarball on some plain-old web host - yes?

The current behavior remains the default, there is and will be no namespace for them. So existing projects aren't affected by this change.

Personal projects are projects that you don't mind if there are public but where collaboration is minimal to non-existent, think dotfiles repos. The chances that someone uses the same dotfiles and come with an PR is low and the point is anyway not to collaborate, just to host those files somewhere.

Hosting private projects is still something that needs to be configured by admins, it will be off by default. In a way, you could see personal projects as private project publicly accessible (private to you, no-one else uses it, but w/o confidential information and thus that can be publicly accessible).

I do not plan on re-implementing GitHub, GitLab, BitBucket or any of those plateform in a 1 to 1 way. Pagure isn't meant to be a python version of GitLab.

ok i need to ask tho because we are planning to move an existing userbase and repos from gogs which has that routing schema and we would need to be sure we can mimic it as not to break existing links - but the most critical point would be that repos placed under a user namespace must not be strictly limited to "personal" mode - we would need repos under a user namespace to be fully featured projects (fully equivalent to those in the global namespace) because we would be excluding the global namespace - obviously we would also need repos to be accessible via git like: git@host:user/repo.git

so although clumsy, the path of least resistance for notabug seems to be the existing "fake-namespace" behaviour

• use the existing "fake-namespace" behaviour for all repos
• create a user in the name of each group
• associate all repos explicitly with a user (or group psuedu-user) on the "create repo" form
• disable global repo routing if necessary and route all repos like: '/namespace/repo'

but maybe i am still misunderstanding the proposal - as i understand it the current behaviour is that when a user creates a project named 'a-project' then a global project is created with a canonical name 'a-project' and accessible at '/a-project' - if a user creates a project named 'a-user/a-project' then a global project is created with a canonical name 'a-user/a-project' fully-featured and equivalent to any other project in the global namespace and accessible at '/a-user/a-project' giving the effect of a 'fake-namespace'

now with the new behavior if the user visits the "create repo" form page and enters 'a-project' in the "Project Name" field then what is the result? - is a limited "personal" repo created with a canonical name 'a-project' and accessible at '/user/a-project' or is it a full-featured global project with a canonical name 'a-project' accessible at '/a-project'? - if the user instead wanted a full-featured namespaced repo could they still enter 'a-user/a-project' in the "Project Name" field and then a "fake-namespace" repo would be created with a canonical name 'a-user/a-project' and accessible at '/a-user/a-project'? - if so then how could the user create a global project? would there be separate forms for these? is the existing 'fake-namespace' behavior disabled when the new behavour is used? or is the existing 'fake-namespace' behavior replaced entirely with the new limited repos?

if the existing 'fake-namespace' behavior is the only way for a full-featured repo to be accessible at a path of the form '/user/repo' and that feature is removed entirely then it is not clear if we would be able to move the existing users and projects from gogs to pagure

if all project types are always available then it is not clear how this works from the user perspective - if there would be essentially 3 classes of repo then one idea would be to have a single "create repo form" with a dropdown HMTL SELECT element with three HTML OPTION:

* global | full-featured    # existing global namespace behaviour
* user   | full-featured    # existing "fake-namespace" behaviour
* user   | limited-features # proposed "personal-repo" behaviour

if done that way then there could be config key introduced to choose which classes of repo to offer on the "create repo" form - in our case we would want to offer only the full-featured user "fake-namespace" type (and perhaps the new "personal-repo" type) and to treat groups as pseudo-users for the purpose of namespacing in order to allow multiple groups to have a duplicated repo name like: /a-group/dotfiles and /another-group/dotfiles

Well real namespace changes nothing compared to the fake-namespace we had before.

You can still create a group per user and put all of their projects under it.

The only "issue" with that workflow is the page to create new project that default to a empty namespace, so if your user aren't careful to set the namespace to their username they will create "top-level" projects.

Personal Project is a complete different idea, it relies on namespace (fake or real) but that is it.

ok so the "fake-name-space" behaviors will not be removed - i am seeing the way forward now assuming all of the following are true:

Given a user exists named 'user1'
Given a group exists named 'group1'
Given a user exists named 'user2'
When 'user1' creates a project named 'user1/project1'
Then a project is created in the global scope with canonical name 'user1/project1'
And the underlying gitolite repo is named 'user1/project1.git'
And the git URL is accessible like: ssh://git@pagure.io/user1/project1.git
When 'user1' creates a project named 'group1/project1'
Then a new project is created in the global scope with canonical name 'group1/project1'
When 'user2' creates a project named 'group1/project1'
Then 'user2' sees "Sorry, a project already exists with that name: 'group1/project1'

if all of the above are true then we could simply validate "project name" to disallow the '/' slash and then programatically prepend the 'user/' prefix to all repo names - in this way the global namespace would be "apparently" disabled and all repos would be "fake-namespaced" to a user

when you suggested creating a group per user i assume that implies that a group can exist with the same name as a user - repos are already strongly coupled to a creator and shown on the user's profile page - im not clear what may be the benefit of creating a group for each user - would this associate their "fake-namespaced" repos with that user somehow more robustly? are there more fine-grained permissions for projects associated with groups?

perhaps that was just in response to my suggestion? - i had suggested creating a user for each group in order to give each group a proper namespace so that group repos could be intrinsically routed like '/group/repo.git' - but if all namespaced repos must be of the limited type than we would just create "fake-namespace" group repos in the same way as with users

So I will be deleting all of @marcusomnis 's project directly in the DB, without trying to figure out if there were potential genuine projects in there.

I realized that I couldn't really do that as otherwise I would have had to clean the FS as well. so I created a new project: https://pagure.io/pagure-utility aiming at storing scripts useful for managing a pagure instance and the first script allows to delete all the projects of a specified user.
@marcusomnis no longer has projects on pagure.io

Yesterday I had a strike the "Eureka" type :)
So I think I found the way to easily implement this while remaining true to our idea for pagure.io but allowing other people to have this behavior if they wish to.

The result of this is a 10 minutes work PR: https://pagure.io/pagure/pull-request/1680 (on which I need to spend another 3 minutes to adjust the doc :))

Commit 3175b106 fixes this issue