Proposal: Unity projects should be wrapped in src/ for impr collab

Unity Engine
, , ,
1

New Unity projects should have the standard all other collab’d projects have:

Unity projects should be wrapped in a src/ dir for improved, modern collaboration.

By keeping the default unwrapped, it leads to bad practices and assumptions that this is the “standard” architecture. By wrapping, benefits include:

  1. Standard architecture for impr clarity and tooling
  2. Separate meta tools with Unity tools
  3. Separate awkward ~Documentation from the standard docs/ top-level dirs
  4. Keep bloaty deployment/helpers +1 outside the Unity project dir

There are surely other reasons beyond this. What’s frustrating is that Unity Hub still disallows renaming projects, despite wrapping core source code being a common practice in all things relating to code+collab.

Prereq: Unity Hub would need to add the very basic feature [requested many years ago, may I passive-aggressively add :stuck_out_tongue:] of allowing name changes to the projects – which should be implemented anyway. I have 10 projects all named src :wink: there are hacky workarounds for this, but no fix.

(PS: Why is an editor version required if Unity Engine topic allows topics such as Hub?)

2

To me, that sounds archaic. It sounds like having to have all sources in a folder named trunk for reasons that befuddle any programmer who hasn’t already been doing corporate software development with source control back in the 80s. We should be fortunate that this forced, rigid structure in source control is a thing of the past!

There’s no improvement in enforcing an arbitrary folder structure. No one structure fits all. Plus the src folder is meant to only contain source code, not assets nor anything else but code and config / make files - certainly not entire Unity projects. You’re trying to enforce an architecture, a workflow onto something to which it is simply not applicable and therefore it’s not surprising that following this discipline is making your life harder with 10 projects named src for no good reason other than wrongfully applied tradition.

But rather than adapt and go with the time, and perhaps maintain an Assets/src folder for your scripts for purely aesthetic and emotional reasons, you request that everyone should adhere to arbitrary nomenclature.

Try to view it from the position of someone who has always had the liberty of naming things the way we like in source control, and you’ll find it hard to argue why enforcing src (or: doc, lib, bin, inc, obj, dep, db, test) helps with anything. :wink:

Also worth noting is that these short names originate in days past where typing time was still an important factor (no autocomplete!), a time when programmers were quite proud of distinguising themselves as l33t by usng obscr and clvr abrrvtns, where each character represented a precious resource on disk (one or even two bytes per character!), and where filenames were restricted to 8+3 characters by the OS, not to mention the maximum length of a path which was as little as 80 bytes (early FAT16 I think, but more commonly yet still restrictive to this day around 240-260 characters depending on OS and use case).

I agree it’s annoying that you have to manually re-add a project after renaming its root folder. On the other hand, how often do we actually need to rename a project in the first place? I do it maybe once when Unity 2022 HDRP Test has eventually grown into an actual project. I can live with that, no biggie.

Still, I’d applaud the ability to rename a project folder from the Hub but there may be good reasons (source control!) not to allow that.

1 Like
3

they might mean renaming project title (not actual folder name, which unity mistakenly has in their product board https://unity.com/roadmap/unity-hub )

*i even tested it in hub while ago, would be pretty easy for unity to do:

** link doesnt seem to jump into correct position on page… but its up there with images

4

It’s entirely possible I’ve been a sheep to the herd of src/ wrappers from complete coincidence that I generally work with long standing repos :thinking: fair enough. It doesn’t need to be src, though, it could be wrapped in anything as long as it’s wrapped. The outside parent is important for meta tooling.

Let’s say online multiplayer. You’ll have separate tooling for deployment in the parent. Or docgen usually goes to docs/, but conflicts with ~Documentation for packages. Meta tooling. Etc. you generally want to separate this stuff however you want to do it, and many services expect root level tooling without having to customize everything to do otherwise.

I’d still like the flexibility to rename, though. That way anyone can do what they want. Sometimes I have 3 copies in the list where 1 is a bak, one is mac build, one is server build, etc. it’s all named the same. The paths don’t even show full on hover, so all the prefixes are the same too since it doesn’t show much.