Re: running macports along with homebrew

On Mar 6, 2018, at 04:00, db wrote: > On 6 Mar 2018, at 10:49, Ryan Schmidt wrote: >> The portindex indexes Portfiles, not portgroups. So the port's version must >> be set in the Portfile, not anywhere else. > > Would then portindex fail if the port's version in the portfile is a variable > set

Re: running macports along with homebrew

On 6 Mar 2018, at 10:49, Ryan Schmidt wrote: > The portindex indexes Portfiles, not portgroups. So the port's version must > be set in the Portfile, not anywhere else. Would then portindex fail if the port's version in the portfile is a variable set to a command?

Re: running macports along with homebrew

On Mar 6, 2018, at 03:47, db wrote: > On 6 Mar 2018, at 02:34, Ryan Schmidt wrote: >> On Mar 5, 2018, at 05:43, db wrote: >>> As I said in my previous post, you can get HEAD's hash with 'git ls-remote >>> --heads'. And store it somewhere. >> Who are you suggesting should run this command and when?

Re: running macports along with homebrew

On 6 Mar 2018, at 02:34, Ryan Schmidt wrote: > On Mar 5, 2018, at 05:43, db wrote: >> As I said in my previous post, you can get HEAD's hash with 'git ls-remote >> --heads'. And store it somewhere. > Who are you suggesting should run this command and when? The port maintainer? > The user trying

Re: running macports along with homebrew

On Mar 5, 2018, at 05:43, db wrote: > On 5 Mar 2018, at 11:39, Ryan Schmidt wrote: >> hash+date is specific, predictable, repeatable. The portfile developer tests >> a specific hash+date, and when satisfied, commits it to make it available to >> MacPorts users. > > As I said in my previous pos

Re: running macports along with homebrew

On 5 Mar 2018, at 11:39, Ryan Schmidt wrote: > hash+date is specific, predictable, repeatable. The portfile developer tests > a specific hash+date, and when satisfied, commits it to make it available to > MacPorts users. As I said in my previous post, you can get HEAD's hash with 'git ls-remote

Re: running macports along with homebrew

Indeed. Db had asked how it would technically be done, eg in his personal repo. I am also on neither side in this. K Sent from my iPhone > On Mar 5, 2018, at 2:39 AM, Ryan Schmidt wrote: > >> On Mar 5, 2018, at 04:34, db wrote: >> >> I know, but I don't see how HEAD is pragmatically that

Re: running macports along with homebrew

On Mar 5, 2018, at 04:34, db wrote: > > I know, but I don't see how HEAD is pragmatically that much different from > the devel ports that use a hash+date instead. "HEAD" is not a specific version. It will vary as developers make new commits. A user installing a port that fetches from "HEAD" wil

Re: running macports along with homebrew

On 4 Mar 2018, at 05:16, Ken Cunningham wrote: >github.setupauthor project HEAD >checksum {} Thanks, Ken. I didn't think it'd be that easy. Only caveat is that it fails the livecheck and there's no way to correlate HEAD to a date. The commit could be read with 'git ls-remote --h

Re: running macports along with homebrew

On 2018-02-13, at 12:20 PM, db wrote: > >> 2. HEAD variants. >> This is a specific MacPorts decision, based on the "reproducible builds" >> philosophy. It's open for debate at times, I would think. It's easy to do >> it, but we just don't do it on purpose. >> I have overridden this and allowe

Re: running macports along with homebrew

On Thu, Feb 15, 2018 at 08:39:23AM -0600, Ryan Schmidt wrote: > On Feb 14, 2018, at 17:16, db wrote: > > > I couldn't find elasticsearch in macports. > > $ port info elasticsearch > elasticsearch @6.1.2 (databases, java) [snip] Not there on my desksystem, but there on one of our test builders; P

Re: running macports along with homebrew

On Feb 14, 2018, at 13:46, Ken Cunningham wrote: > On 2018-02-14, at 5:56 AM, Ryan Schmidt wrote: > > >> We will definitely never offer a user-facing feature for building the HEAD >> version of a port's code. > > > I completely recognize why you stick with this, I totally get it, but this

Re: running macports along with homebrew

On Feb 14, 2018, at 17:16, db wrote: > On 14 Feb 2018, at 14:56, Ryan Schmidt wrote: >> I'm aware of "cask" being a feature of Homebrew. If that's what you're >> referring to, what does the feature do / what do you want MacPorts to do in >> regard to this? > > Manage (and here the terminology

Re: running macports along with homebrew

On Feb 14, 2018, at 17:42, Michael wrote: >> I think we should look at ways in which MacPorts is harder to use and see if >> we can address those. > > I'd say that being able to install software without having to use sudo would > be my number one. Step 1: edit the sudoers file so that you are

Re: running macports along with homebrew

> On Feb 14, 2018, at 2:46 PM, Ken Cunningham > wrote: > > 1. a one-line copy-paste install script that can be embedded into any webpage. I could never understand that this is considered an advantage of Homebrew. The idea of running a random script directly from a web page that purports to i

Re: running macports along with homebrew

Hi On 14/02/18 23:42, Michael wrote: I think we should look at ways in which MacPorts is harder to use and see if we can address those. I'd say that being able to install software without having to use sudo would be my number one. Personally, one of the reasons I choose MacPorts over the

Re: running macports along with homebrew

Le 15/02/2018 à 00:42, Michael a écrit : I think we should look at ways in which MacPorts is harder to use and see if we can address those. I'd say that being able to install software without having to use sudo would be my number one. So, maybe a --user switch, similar to Python pip's ? Or,

Re: running macports along with homebrew

> On 15 Feb 2018, at 9:28 am, db wrote: > … > I couldn’t care less about polls, but I do care that quite often, when I find > an interesting piece of software at github, the developer recommends homebrew. That’s the problem I’m seeing. I just installed clojure 1.9 from homebrew, because only

Re: running macports along with homebrew

> I think we should look at ways in which MacPorts is harder to use and see if > we can address those. I'd say that being able to install software without having to use sudo would be my number one. My number two would be an easier way to deal with multiple variants, especially the whole X11 ver

Re: running macports along with homebrew

On 14 Feb 2018, at 20:46, Ken Cunningham wrote: > In a recent poll > , homebrew was > recommended 375 to 25 over MacPorts. > Most developers who offer their software for download and building manually > recommend homebrew for support

Re: running macports along with homebrew

On 14 Feb 2018, at 19:20, Ken Cunningham wrote: > For git, I'd have to look at the github portgroup to see how to do that. > But as you heard from Ryan, it appears it's not ever going to make it into > macports in general… Yeah, the thing is having at the very least the feature for local use.

Re: running macports along with homebrew

On 14 Feb 2018, at 14:56, Ryan Schmidt wrote: > I'm aware of "cask" being a feature of Homebrew. If that's what you're > referring to, what does the feature do / what do you want MacPorts to do in > regard to this? Manage (and here the terminology gets trickier) more generally available applic

Re: running macports along with homebrew

On Feb 14, 2018, at 5:33 PM, Ken Cunningham wrote: > homebrew is easier to use, and works for 99% of people without any trouble. > > MacPorts is better in most ways, but a bit harder to use, and has more of a > learning curve to it. I think we should look at ways in which MacPorts is harder to

Re: running macports along with homebrew

One of the reasons I prefer MacPorts is that it does NOT install in /usr/local. I am still in the habit of thinking that /usr/local is a system directory that is expected to be inaccessible to the masses (me in this case.) Some independent installers, like that for mysql, installed in /usr/loca

Re: running macports along with homebrew

Me too. I certainly don't have any interest in turning this into another /usr/local rehash, for sure, as that is pointless. Just recognizing what is going on out there, and trying to stay as relevant as possible in a VHS / Beta sorta way. homebrew is easier to use, and works for 99% of people w

Re: running macports along with homebrew

On Feb 14, 2018, at 2:46 PM, Ken Cunningham wrote: > On 2018-02-14, at 5:56 AM, Ryan Schmidt wrote: >> We will definitely never offer a user-facing feature for building the HEAD >> version of a port's code. > > I completely recognize why you stick with this, I totally get it, but this > cauti

Re: running macports along with homebrew

On 2018-02-14, at 5:56 AM, Ryan Schmidt wrote: > We will definitely never offer a user-facing feature for building the HEAD > version of a port's code. I completely recognize why you stick with this, I totally get it, but this caution is costing MacPorts both users and mindshare to do so...

Re: running macports along with homebrew

On 2018-02-13, at 12:20 PM, db wrote: > > I have some devel ports locally, that I have to manually update for the > latest commit, instead of automatically updating for the current master. I > have to check that wielands port. > widelands uses bzr, so it's easy to force it to the current comm

Re: running macports along with homebrew

On Feb 13, 2018, at 08:40, db wrote: > On 13 Feb 2018, at 07:01, Ken Cunningham wrote: >> If there is anything worth having in MacPorts that is in Homebrew but not >> MacPorts, just ask for it. > > I'm trying homebrew as a fallback for MacPorts, but since you said anything, > here's a wish list

Re: running macports along with homebrew

On 13 Feb 2018, at 19:52, Ken Cunningham wrote: > 1. cask: > […] > I think nobody finds this in general to be all that magical or useful though, > and so nobody bothers to spend any time on building these sorts of Portfiles. > You want Adobe Air? Just go to the website and install it. It's goin

Re: running macports along with homebrew

On 2018-02-13, at 6:40 AM, db wrote: > On 13 Feb 2018, at 07:01, Ken Cunningham > wrote: >> If there is anything worth having in MacPorts that is in Homebrew but not >> MacPorts, just ask for it. > > I'm trying homebrew as a fallback for MacPorts, but since you said anything, > here's a wish

Re: running macports along with homebrew

On 13 Feb 2018, at 07:01, Ken Cunningham wrote: > If there is anything worth having in MacPorts that is in Homebrew but not > MacPorts, just ask for it. I'm trying homebrew as a fallback for MacPorts, but since you said anything, here's a wish list: cask, building from HEAD, LinuxPorts (analog

Re: running macports along with homebrew

On 12 Feb 2018, at 23:08, Jeremy Lavergne wrote: > MacPorts can deny any access to Homebrew during builds in trace mode. > Less invasive than renaming files or folders. >> port -t install PORTNAME Depending on who you ask, there's much overhead, in any case, >%50.

Re: running macports along with homebrew

If I might suggest something to make this issue easier, If there is anything worth having in MacPorts that is in Homebrew but not MacPorts, just ask for it. Most of these ports take 10 to 20 minutes to make. Some a bit longer, if they are weird in some way. Best, Ken

Re: running macports along with homebrew

On 02/12/2018 09:14 AM, db wrote: > Would it suffice to rename /usr/local during build time to avoid any > conflicts? I ask because I just want to make sure that I'm not missing > anything else. MacPorts can deny any access to Homebrew during builds in trace mode. Less invasive than renaming fi

Re: running macports along with homebrew

On 12 Feb 2018, at 16:13, Mojca Miklavec wrote: > Exceptions might occur for formulas that put stuff outside of /usr/local AFAIR from the documentation everything that's built locally is contained in so-called cellars under its prefix, so I could just rename it (no SIP or SIP disabled) or move

Re: running macports along with homebrew

On 12 February 2018 at 15:14, db wrote: > Would it suffice to rename /usr/local during build time to avoid any > conflicts? I ask because I just want to make sure that I'm not missing > anything else. As far as MacPorts is concerned, I assume it should be mostly OK if you temporarily move HomeBr

Re: running macports along with homebrew

Would it suffice to rename /usr/local during build time to avoid any conflicts? I ask because I just want to make sure that I'm not missing anything else.

Re: running macports along with homebrew

On 2 Sep 2017, at 01:06, Ryan Schmidt wrote: >> On Sep 1, 2017, at 03:22, db wrote: >> On 31 Aug 2017, at 21:34, Craig Treleaven wrote: >>> Gentle reminders, regularily applied, tend to cure the ‘missing ports and >>> updated versions’ issue. >> It shouldn't work like that. Actually, it didn't.

Re: running macports along with homebrew

> On Sep 1, 2017, at 03:22, db wrote: > > On 31 Aug 2017, at 21:34, Craig Treleaven wrote: >> Gentle reminders, regularily applied, tend to cure the ‘missing ports and >> updated versions’ issue. > > It shouldn't work like that. Actually, it didn't. Ok. How would you like us to proceed?

Re: running macports along with homebrew

On 31 Aug 2017, at 21:34, Craig Treleaven wrote: > Gentle reminders, regularily applied, tend to cure the ‘missing ports and > updated versions’ issue. It shouldn't work like that. Actually, it didn't. > I understand the attraction to having a command line way to check for and > update my majo

Re: running macports along with homebrew

On 31 Aug 2017, at 21:46, Daniel J. Luke wrote: > Indeed, a quick look at pacakges.macports.org indicates there are 22,957 > binary archives available. As of now 19944 ports. No vagrant, no stem — yet.

Re: running macports along with homebrew

On Aug 31, 2017, at 10:53, Ken Cunningham wrote: > I think homebrew gets attention for two reasons. > > > 1. a one-line copy & paste install command that is pasted into the terminal > (macports could / should do that too, BTW). While I agree our web site, including installation instructions,

Re: running macports along with homebrew

On Aug 31, 2017, at 3:34 PM, Craig Treleaven wrote: > AIUI, casks are supposed to help in two ways: binary (only) packages and > pre-compiled binaries. > > MacPorts solved the second part several years ago. As an aside, I think a > lot of people using Homebrew never got this message. Indeed,

Re: running macports along with homebrew

> On Aug 31, 2017, at 9:46 AM, db wrote: > > On 31 Aug 2017, at 15:35, Craig Treleaven wrote: >> What is it that you want that MacPorts does not provide? > > As I said in my OP, missing ports and updated versions, cask... Gentle reminders, regularily applied, tend to cure the ‘missing ports an

Re: running macports along with homebrew

On 31 Aug 2017, at 17:53, Ken Cunningham wrote: > I think homebrew gets attention for two reasons. > > > 1. a one-line copy & paste install command that is pasted into the terminal > (macports could / should do that too, BTW). > > 2. the fact that it symlinks it's stuff into /usr/local, maki

Re: running macports along with homebrew

I think homebrew gets attention for two reasons. 1. a one-line copy & paste install command that is pasted into the terminal (macports could / should do that too, BTW). 2. the fact that it symlinks it's stuff into /usr/local, making it easier to use it's installed products for building other

Re: running macports along with homebrew

On 31 Aug 2017, at 15:35, Craig Treleaven wrote: > What is it that you want that MacPorts does not provide? As I said in my OP, missing ports and updated versions, cask...

Re: running macports along with homebrew

> On Aug 31, 2017, at 9:32 AM, db wrote: > > On 30 Aug 2017, at 10:16, Richard L. Hamilton wrote: >> the newer, safer convention is distinct subdirectories of /opt, for each >> package or set of commonly managed packages; thus, MacPorts by default uses >> /opt/local, XQuartz uses /opt/X11 (for

Re: running macports along with homebrew

On 30 Aug 2017, at 10:16, Richard L. Hamilton wrote: > the newer, safer convention is distinct subdirectories of /opt, for each > package or set of commonly managed packages; thus, MacPorts by default uses > /opt/local, XQuartz uses /opt/X11 (for the stuff that's not elsewhere), etc. Is it a ta

Re: running macports along with homebrew

> On Aug 29, 2017, at 18:54, db wrote: > > On 29 Aug 2017, at 23:24, Ryan Schmidt wrote: >> The best practice is not to do that. We don't support it. It can cause you >> problems that we don't want to spend time investigating, because they >> wouldn't be problems if you hadn't also used a sec

Re: running macports along with homebrew

On 29 Aug 2017, at 23:39, Mojca Miklavec wrote: > But most important: in case you do end up with two systems, make sure to > quadruple check before submitting any bug reports to make sure that the error > is not due to the packages intermixed with each other. I'm well aware of that. At any rate

Re: running macports along with homebrew

On 29 Aug 2017, at 23:24, Ryan Schmidt wrote: > The best practice is not to do that. We don't support it. It can cause you > problems that we don't want to spend time investigating, because they > wouldn't be problems if you hadn't also used a second package manager. You already made the same p

Re: running macports along with homebrew

On 29 Aug 2017, at 19:27, Ken Cunningham wrote: > FYI, it's actually not hard to write a portfile to install a binary, and it's > useful in some cases. Yes, but cask already has 3.7K. Convenient, isn't it? > But MacPorts so far has explicitly stated they are not interested in getting > into t

Re: running macports along with homebrew

On 08/30/2017 12:17 AM, Mojca Miklavec wrote: > On 29 August 2017 at 23:43, David Strubbe wrote: >> Hi Mojca, >> >> How do you hide a prefix when installing? > > You could have your path set to something like > > > /opt/local/bin:/opt/local/sbin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbi

Re: running macports along with homebrew

On 29 August 2017 at 23:43, David Strubbe wrote: > Hi Mojca, > > How do you hide a prefix when installing? You could have your path set to something like /opt/local/bin:/opt/local/sbin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin and then you would set it to

Re: running macports along with homebrew

Hi Mojca, How do you hide a prefix when installing? David On Tue, Aug 29, 2017 at 2:39 PM, Mojca Miklavec < mojca.miklavec.li...@gmail.com> wrote: > On 29 August 2017 at 23:24, Ryan Schmidt wrote: > > On Aug 29, 2017, at 07:08, db wrote: > > > >> best practice f

Re: running macports along with homebrew

On 29 August 2017 at 23:24, Ryan Schmidt wrote: > On Aug 29, 2017, at 07:08, db wrote: > >> best practice for running macports along with homebrew > > The best practice is not to do that. We don't support it. It can cause you > problems that we don't want to spend t

Re: running macports along with homebrew

On Aug 29, 2017, at 07:08, db wrote: > best practice for running macports along with homebrew The best practice is not to do that. We don't support it. It can cause you problems that we don't want to spend time investigating, because they wouldn't be problems if you hadn&#x

Re: running macports along with homebrew

On Tue, Aug 29, 2017 at 7:40 PM, db wrote: > On 29 Aug 2017, at 14:55, Umesh Singla wrote: > > /opt/local/bin:/opt/local/sbin:/usr/local/gradle/gradle- > 2.11/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin > > > > It simply looks for the packages in the default macports directory

Re: running macports along with homebrew

> Besides missing ports and updated versions, what appeals to me from homebrew > is cask (I have to read its documentation though), which could even install > macports. FYI, it's actually not hard to write a portfile to install a binary, and it's useful in some cases. Here's one I wrote

Re: running macports along with homebrew

On 29 Aug 2017, at 14:55, Umesh Singla wrote: > /opt/local/bin:/opt/local/sbin:/usr/local/gradle/gradle-2.11/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin > > It simply looks for the packages in the default macports directory > (/opt/local) first and then others, I guess. Though

Re: running macports along with homebrew

I don't have much to add regarding using both. I know there have been efforts to sandbox MacPorts such that it won't see libraries from other prefixes. I'm not sure what state that is in currently. On Tue, Aug 29, 2017 at 8:55 AM, Umesh Singla wrote: > Though I constantly run into problems with d

Re: running macports along with homebrew

-both-homebrew-and-macports-on-your-os-x/ - Umesh Umesh Singla On Tue, Aug 29, 2017 at 5:38 PM, db wrote: > I searched the docs, the list's archive and stackexchange amongst other > sources for sort of a best practice for running macports along with > homebrew, to no avail. > &

running macports along with homebrew

I searched the docs, the list's archive and stackexchange amongst other sources for sort of a best practice for running macports along with homebrew, to no avail. From those I gathered that the only problem one could run into, it seems, would be at build time — hence some advise on cha