Comments (16)
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
from haikuporter.
@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 :(
from haikuporter.
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.
from haikuporter.
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?
from haikuporter.
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.
from haikuporter.
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.
from haikuporter.
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.
from haikuporter.
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.
from haikuporter.
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?
from haikuporter.
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.
from haikuporter.
This series of commits was messy anyway, didn't explain anything why it was done.
I miss why the folder can't be renamed.
from haikuporter.
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.
from haikuporter.
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.
How about moving haikuporter.py and Haiku porter to a subdir then?
from haikuporter.
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.
from haikuporter.
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.
from haikuporter.
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 ;)
from haikuporter.
Related Issues (20)
- Unable to build source packages after 5cecf6a0 HOT 7
- Using fixCMake doesn't work as expected. HOT 1
- Warning: POLICY ERROR: no matching self provides for "libart_lgpl_devel"
- Explicitly state which dependency could not be satisfied (or why) HOT 4
- buildmaster needs to leverage object storage HOT 23
- Use python packaging.Version to handle versioning inside HaikuPorter instead of custom solution HOT 7
- Changes committed to the master without PR HOT 1
- Using multiple underscores in recipe name/port name doesn't work for secondary architecture (32bit) HOT 3
- [enhancement] Add RSS/Atom feed for failed builds (skipped ones too?).
- Block builds from creating/deleting users/groups HOT 6
- pip3 install no longer adds executable to path HOT 6
- Reintroduce the lib:libstdc++ dependency in haikuporter
- can only concatenate str on --why
- Haikuporter makes too many assumptions about directories existing HOT 2
- When the PATCH function fails, haikuporter resets to ORIGIN, removing patchset commits
- Draft new tagged release? HOT 2
- [idea] extract package for handling recipe-related stuff HOT 8
- Write appendix to the coding guidelines for Python development
- Create CONTRIBUTION document
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from haikuporter.