haikuporter
haikuporter copied to clipboard
haikuports
Cannot clone repository properly on MacOS
Hi, after last commits I cannot clone repository properly (with preserving all files and directories) on MacOS:
$ git clone [email protected]:jurgenwigg/haikuporter.git
Cloning into 'haikuporter'...
remote: Enumerating objects: 6334, done.
remote: Counting objects: 100% (700/700), done.
remote: Compressing objects: 100% (333/333), done.
remote: Total 6334 (delta 419), reused 586 (delta 354), pack-reused 5634
Receiving objects: 100% (6334/6334), 1.86 MiB | 504.00 KiB/s, done.
Resolving deltas: 100% (4523/4523), done.
warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:
'haikuporter'
You can clone the repository by creating a case-sensitive filesystem image, the same as for building Haiku. Here's an old guide that details how to do it: https://www.haiku-os.org/articles/2015-02-05_building_haiku_mac_os_x_1010_yosemite/#disk_image
@jurgenwigg made some simple renaming changes to fix this and they were cancelled by a later change.
I think we should really fix this repository to be cloneable without such complicated setup. Why is that so hard to do? It's just about renaming a single file :(
We can also change path to the source code by just moving files from HaikuPorter directory to the src/HaikuPorter. Some minor fixes in the imports inside, but external API (script file name) should be the same. The best way would be to suggest and promote approach to just install the HaikuPorter package in the system with pip command and use it as a normal OS command to build the packages.
The reversion was done by @korli.
to just install the HaikuPorter package in the system with pip command
But HaikuPorter does have real usages outside of Haiku, namely bootstrap cross-compile builds, which are not done with installed toolchains. That would be the primary usecase for HaikuPorter on macOS. As the Haiku repository itself cannot be checked out at all, much less built, on a case-insensitive filesystem, why does it matter that HaikuPorter can't be, either?
There are many use cases and reasons to make possible for the people to normally (without any issues) clone repository. Before doing any further refactoring or cleanup we should write unit and integration test for the existing code. This should be possible to be done on any OS.
Since HaikuPorter can be used for cross compilation it shouldn't depend on case sensitivity of the OS.
There are many use cases and reasons to make possible for the people to normally (without any issues) clone repository.
Like what?
This should be possible to be done on any OS.
It is possible. Just create a case-sensitive disk image using DiskUtility, the same as when cloning the Haiku repository.
it shouldn't depend on case sensitivity of the OS.
It does, and so does Haiku's cross-compilation process. You can simply create a case-sensitive disk image on macOS and use that, as Haiku developers who use Macs already do.
It is the 4th time we are having this discussion now, that's ridiculous.
Can we just rename one file or move one directory? This should cost about zero effort. There are no downsides. Why are we wasting time arguing about it?
We should just make a simple change and allow cloing Haikuporter on Windows and Mac OS to work. There is no reason to keep things the way they are now.
Why are you insisting on not making this simple change?
Reasons why this can be useful (already mentioned the previous times we had this discussion, but I will repeat them again...)
- Archiving: people may just want to clone the repo and keep a copy around on another OS. Or store it on a FAT partition in Haiku. Or whatever. Really, it's none of our business if they want to do that.
- Use of haikuporter for non-Haiku recipes: why not, after all? If someone wanted to do this, they certainly could.
- Ease of contributing: sometimes people may not be at their main machine (for example, they are using a different computer at their paid work, or whatever). In this case, being able to checkout the sources for haikuports and making a quick and simple fix can be useful. It should not need setting up a case sensitive disk image
- People may use this on WSL, which shares files between Windows and Linux, and use Git from Windows but do all other things from the Linux environment (or the same with a VM and shared folders)
For Haiku, supporting all these usecases would be hard, nonetheless, it is possible to clone the repo from MacOS without problems. It's only the building of Haiku that will be problematic, and that would require a nontrivial amount of work to fix, so we may not do it. But here? It's just a single file to rename.
This should cost about zero effort.
Except there are usages of haikuporter directly from this repository in other repositories, including HaikuPorts itself, the Haiku build system, the buildmaster Docker container setup, and more. Finding all of them and renaming them across 3-6 repositories is definitely going to be more than "zero effort". I think these problems were the reason for the immediate reversion.
Archiving: people may just want to clone the repo and keep a copy around on another OS.
That's what git clone --bare is for.
People may use this on WSL, which shares files between Windows and Linux, and use Git from Windows but do all other things from the Linux environment (or the same with a VM and shared folders)
Windows has case-sensitive NTFS for WSL. I have the main Haiku repository checked out on case-sensitive NTFS, and it works great. Unlike macOS, it's completely transparent; you don't need to make a separate disk image for it.
It's only the building of Haiku that will be problematic
We support building Haiku on macOS already and there are developers who do just that (e.g. jscipione), using a case-sensitive disk image.
The initial proposal (renaming the haikuporter directory instead of the script) was rejected.
The second proposal (moving the haikuporter directory to an src subdirectory) was also rejected.
As far as I can see, both of these would work just fine without any changes needed elsewhere. Am I missing something?
Next option would be setting core.ignoreCase in git config to false but it's not working. Overall keeping two files with almost the same name is seen as a bad practice and is not recommended.
Where and how is used HaikuPorter script? We need to find out most use cases for it to make the good decision.
This series of commits was messy anyway, didn't explain anything why it was done.
I miss why the folder can't be renamed.
Next option would be setting core.ignoreCase in git config to false but it's not working.
This works with a case-sensitive disk image. Did you follow the instructions here? https://www.haiku-os.org/articles/2015-02-05_building_haiku_mac_os_x_1010_yosemite/#disk_image
This works for other Haiku developers just fine, I know @jscipione develops on macOS with case-sensitive disk images.
I miss why the folder can't be renamed.
I think it needs to keep the name HaikuPorter to behave as a Python module with that name, so it would have to be moved to a subdirectory or something like that.
I think it needs to keep the name
HaikuPorterto behave as a Python module with that name, so it would have to be moved to a subdirectory or something like that.
How about moving haikuporter.py and Haiku porter to a subdir then?
Disk image works fine. Nevertheless I think forcing users to create disk image for this repo is a wrong thing. There should be a note about that in the documentation for the HaikuPorter. Someone working on exFAT (any removable flash drive) will have the same issue. Sharing files to another file systems can also cause some issues (sharing files through SMB for example). I know that nowadays we are all working in the cloud in many cases and my use cases (sharing through SMB) are not used anymore. I think that no-one is making backups on CDs (ISO9660 is case insensitive) and storing this repo there will be not a problem :) Moving to, i.e. src dir can cause some issue with imports, etc., but it would be easier to do and fix than changing the haikuporter -> haikuporter.py. Personally I'm against having identical file names that differs in letter sizes. I would prefer to package HaikuPorter properly, install it in the OS and just use it as all other apps.
It is packaged properly for Haiku (as an hpkg file) already. Use on other OS is quite limited (only for Haiku bootstrap) for now, unless you have plans to change that?
We should still fix this issue, of course, and maybe do a "proper" Python packaging as well.
Making proper python package is almost done. Whole source from haikuporter script can be placed inside the Main.py file with if __name__ == "__main__": section. Then, in pyproject.toml section for entry point is placed with name which will be available after package installation. The same functionality is provided by the cookiecutter package, poetry and many others.
About other uses - I've just started to dig deep into haikuporter and all functionality provided by the package ;)