Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Baseline Mac OS X Support merged into FreeBSD package manager

github.com

Post reply on HN
Print view View original

51–60 of 61 posts

Re: Baseline Mac OS X Support merged into FreeBSD package manager

#51

Post by chriswarbo »

jfroma wrote: post #41
lumpypua wrote: post #35

Earlier quoted context omitted.

How the fuck do people do this with git? I loved doing pretty commits with mercurial's patch queue. Git is awesome but it seems like the only option for pretty commits is rebase (ew). All the git patch queue implementations are basically dead or unmaintained. :(

Yes, one trick I use a lot is interactive rebase. I do a lot of commits with "WORK IN PROGRESS" then git rebase -I HEAD~X to improve the history before pushing. IMHO mercurial is superior to git in a lot of aspects, but there is main philosophical difference in the usage. Mercurial is more about indelible history while git people love to edit the history of the commits.

> git people love to edit the history of the commits

It varies. I avoid editing the history and make my opinion known whenever the topic comes up. Editing the history now requires making assumptions about what future developers might want or need; making assumptions like this is similar to a form of You Ain't Gonna Need It (YAGNI). It's better to give the future developers everything that we have, no matter how "ugly", and allow them to get what they actually need out of it.

In a previous life, our development workflow required rebasing as one of the steps for permission reasons (only senior devs could merge branches into master, so having everyone rebase first made sure conflicts were resolved by the branch's author)

Re: Baseline Mac OS X Support merged into FreeBSD package manager

#52

Post by Nullabillity »

thoughtpolice wrote: post #48
Nullabillity wrote: post #46

Earlier quoted context omitted.

Rewrites history. Also, Mercurial allows you to version control your patch queue (WIP commits).

How is this different from the information stored in `git reflog`, which allows you to rollback to commits before their rebase? You can just as easily revert back to the old version, since it never goes anywhere. Besides, the need to perfectly preserve history in most cases is totally overblown AFAICS, especially local history nobody else sees. I don't care if a person who submitted patches to me made 20 separate min…

> How is this different from the information stored in `git reflog`, which allows you to rollback to commits before their rebase? You can just as easily revert back to the old version, since it never goes anywhere.

Patch queues make the distinction between mutable WIP patches and finished commits explicit. Also, versioned patch queues make it safe to share WIP patches.

Re: Baseline Mac OS X Support merged into FreeBSD package manager

#53

Post by mikemcquaid »

mikepurvis wrote: post #40
mikemcquaid wrote: post #30

Earlier quoted context omitted.

For a long time bottling was just done by me on my local VMs. It's pretty simple really; `brew install --build-bottle wget && brew bottle --root-url youweb.com wget`, upload the outputted bottles somewhere and add the `bottle do` block into the formula file. You can go a step further with this by using the `brew test-bot.rb` script ( https://github.com/Homebrew/homebrew/blob/master/Library/Hom... ) that we use for ou…

That's fair, thanks for the response! The use case I'm interested in would be running the test-bot automatically in a Jenkins/buildbot/whatever environment, where you point the bot at a repo of Formulae and it dumps bottles to a storage provider like S3. Once the dependency caching issue is resolved, I'm interested in getting this to a point of anyone being able to relatively trivially deploy it. The other use case w…

I'm not sure what the dependency caching issue has to do with bottling?

The latter use-case I don't have any particular interest in writing code for myself but I'd consider merging PRs for. The prior is possible with brew-test-bot if you do the uploading yourself (although I may be adding S3 support in the coming months). Using Jenkins should make all of this pretty trivial as-is.

Re: Baseline Mac OS X Support merged into FreeBSD package manager

#54

Post by lumpypua »

seivadmas wrote: post #39
lumpypua wrote: post #35

Earlier quoted context omitted.

How the fuck do people do this with git? I loved doing pretty commits with mercurial's patch queue. Git is awesome but it seems like the only option for pretty commits is rebase (ew). All the git patch queue implementations are basically dead or unmaintained. :(

I haven't used it much so please forgive my ignorance, but what is wrong with git rebase?

Just the user interface. It's a lot easier to fuck up during a rebase. MQ is a lot like git stash on steroids. Super easy to flit between multiple patches that I'm working on and put a change in the appropriate one. Wasn't uncommon for me to touch 3-4 patches in a random order over the course of a few minutes.

Let's say I'm working on patches 1, 2, and 3.

--

Situation: Currently on 3. I write some code and decide it should be in patch 1.

Git: Can't interactively rebase with uncommitted changes. Some sort of stash juggling.

MQ: Go down two patches. Commit the changes to the patch.

--

Situation: I'd like to introduce a new intermediate patch 1.5.

Git: Make a new commit on top of patch 1, rebase the other patches on top of it. If there's potentially conflicting merge errors they need to be addressed immediately—or I'm stuck leaving an alternate history of commit 1 around until I'm ready to deal with merge issues.

MQ: Go down two patches. Make a new patch. Deal with the merge errors whenever I go up/apply patches 2 and 3.

Re: Baseline Mac OS X Support merged into FreeBSD package manager

#55

Post by Camillo »

patrickmay wrote: post #49
Camillo wrote: post #47

Earlier quoted context omitted.

You can install Homebrew in a different place if you want. I have an install inside my home directory.

How does it work in practice? I tried it about a year ago and it still stomped on /usr/local for some packages. If I remember correctly, that was due in part to the package not making it easy to install elsewhere, but Homebrew didn't handle it well.

It always worked fine for me. /usr/local is not even writable by the user I normally use, so it would have caused an error if Homebrew tried writing there - which it didn't. If you're seeing issues when installing to alternate locations, file a bug report.

Re: Baseline Mac OS X Support merged into FreeBSD package manager

#56

Post by mikepurvis »

mikemcquaid wrote: post #53
mikepurvis wrote: post #40

Earlier quoted context omitted.

That's fair, thanks for the response! The use case I'm interested in would be running the test-bot automatically in a Jenkins/buildbot/whatever environment, where you point the bot at a repo of Formulae and it dumps bottles to a storage provider like S3. Once the dependency caching issue is resolved, I'm interested in getting this to a point of anyone being able to relatively trivially deploy it. The other use case w…

I'm not sure what the dependency caching issue has to do with bottling? The latter use-case I don't have any particular interest in writing code for myself but I'd consider merging PRs for. The prior is possible with brew-test-bot if you do the uploading yourself (although I may be adding S3 support in the coming months). Using Jenkins should make all of this pretty trivial as-is.

The dependency caching is orthogonal to bottling; it's just that there's little incentive for me or anyone else to set up or document the bottling process (for ROS on OS X) until the created bottles are usable, which is not presently the case.

Re: Baseline Mac OS X Support merged into FreeBSD package manager

#57

Post by skuhn »

mikemcquaid wrote: post #32
skuhn wrote: post #12

Earlier quoted context omitted.

It can be done (I'm doing it in production), but it is not thought out with this situation in mind. I forked the formula repo at some point in the distant past, and untar it onto each machine. Then I manually manage dependencies when I tell it to fetch bottles from my own source. A lot of the simplicity and 'it just works' nature of Homebrew is because it's meant to be used in one situation and that's it.

You probably want to be using your own tap and the `root_url` in `bottle do` blocks. I'm open to improving your use-case if you can file a feature request about what you're trying to do. Thanks!

Thanks for the reply. My main beef is that I don't terribly want to modify each standard formula (causing more work when I do sync with upstream), but I want the system to be completely self-contained.

Most package managers separate these concerns. There's the package build stuff (debian dir, spec files, etc.), there's the package install stuff (living inside the packages), and there's the repo stuff (apt, yum). Homebrew's inclusion of the install / dep portion inside the formula rather than inside the built bottle make it kind of impossible to fit into the method that I'm accustomed to. Not really sure that such a fundamental change is worthwhile for you to implement, since 99% of your users probably don't want to install their own bottles from a local repo and not connect to the Internet for anything.

Re: Baseline Mac OS X Support merged into FreeBSD package manager

#58

Post by mikemcquaid »

mikepurvis wrote: post #56
mikemcquaid wrote: post #53

Earlier quoted context omitted.

I'm not sure what the dependency caching issue has to do with bottling? The latter use-case I don't have any particular interest in writing code for myself but I'd consider merging PRs for. The prior is possible with brew-test-bot if you do the uploading yourself (although I may be adding S3 support in the coming months). Using Jenkins should make all of this pretty trivial as-is.

The dependency caching is orthogonal to bottling; it's just that there's little incentive for me or anyone else to set up or document the bottling process (for ROS on OS X) until the created bottles are usable, which is not presently the case.

The bottles are usable? Homebrew and some other third parties already use bottles. If they aren't working for you: please create an issue so we can fix them. Thanks!

Re: Baseline Mac OS X Support merged into FreeBSD package manager

#59

Post by mikemcquaid »

skuhn wrote: post #57
mikemcquaid wrote: post #32

Earlier quoted context omitted.

You probably want to be using your own tap and the `root_url` in `bottle do` blocks. I'm open to improving your use-case if you can file a feature request about what you're trying to do. Thanks!

Thanks for the reply. My main beef is that I don't terribly want to modify each standard formula (causing more work when I do sync with upstream), but I want the system to be completely self-contained. Most package managers separate these concerns. There's the package build stuff (debian dir, spec files, etc.), there's the package install stuff (living inside the packages), and there's the repo stuff (apt, yum). Home…

If you create a tap rather than using a fork then this problem goes away as you'll never need to sync with upstream and can provide `root_url`s in your tap so your users can download things from e.g. local URLs.

Re: Baseline Mac OS X Support merged into FreeBSD package manager

#60

Post by tomphoolery »

patrickmay wrote: post #49
Camillo wrote: post #47

Earlier quoted context omitted.

You can install Homebrew in a different place if you want. I have an install inside my home directory.

How does it work in practice? I tried it about a year ago and it still stomped on /usr/local for some packages. If I remember correctly, that was due in part to the package not making it easy to install elsewhere, but Homebrew didn't handle it well.

It definitely shouldn't do that. Most likely that's a fault with the way the formula or Makefile is written, like hardcoding `/usr/local` instead of using $PREFIX.
Post reply on HN