Please Add HeapCL portfile

[ben@…]

Should be within office.

Thanks!

[ben@…]

Updated Portfile. Sorry

[ryandesign (Ryan Carsten Schmidt)]

Some remarks:

• You shouldn't use "system" just to create symlinks; MacPorts has an "ln" Tcl procedure for this. But even more importantly, why are you turning off the python portgroup's binary linking function, then doing it manually? On the assumption that you just don't want the binaries to be suffixed with the python version number, that's very simply accomplished: just write this line:

  python.link_binaries_suffix
  

• The upstream server only offers unversioned distfiles but you've got the port set up to fetch a versioned distfile. This succeeds because the upstream server is misconfigured; in fact you could request any version number of the heapCL distfile and you'd get the currently available one. Which means as soon as they do release a new version, users will start reporting checksum mismatches to you. You should advise the developers to offer standard immutable versioned distfiles like everybody else does.

[ryandesign (Ryan Carsten Schmidt)]

Oh and:

• The python24/python25/python26/python27/python31/python32 portgroups are deprecated and should not be used for new ports; use the new unified python portgroup instead.

[ben@…]

Replying to ryandesign@…:

Some remarks:

• You shouldn't use "system" just to create symlinks; MacPorts has an "ln" Tcl procedure for this. But even more importantly, why are you turning off the python portgroup's binary linking function, then doing it manually? On the assumption that you just don't want the binaries to be suffixed with the python version number, that's very simply accomplished: just write this line:

  python.link_binaries_suffix
  

• The upstream server only offers unversioned distfiles but you've got the port set up to fetch a versioned distfile. This succeeds because the upstream server is misconfigured; in fact you could request any version number of the heapCL distfile and you'd get the currently available one. Which means as soon as they do release a new version, users will start reporting checksum mismatches to you. You should advise the developers to offer standard immutable versioned distfiles like everybody else does.

Hi Ryan -

Thanks for all your help!

The server wasn't misconfigured, that was on purpose and specifically for mac ports. I found specifying the distfile directly resulted in it trying to change to a directory (on the local system) that doesn't exist. We *really* don't want to provide old versions of the software (and the portfile creation is something I added to the build process that creates all of the versions for the various platforms so they shouldn't be out of sync). Because (Heap|Torch)CL is a client that talks to the webservice API, old versions actually cause us to have to support older versions of the API for longer. In fact, we don't have version numbers, we have sha1 hashes (as our versions) -- the version numbers are entirely for mac ports (and if they install them manually, they update based on the hash). That said, I've placed a versioned file on the server for both products. I've also added a cleanup routine to delete all but the latest 3 versions, if you require more let me know.

Now, to the linking thing. So I tried the built in method first, and bluntly it didn't work. So, I went and looked at how Google CL handled the problem. They did/do what I put in that file. That said, if you are saying that the linking is something new/fixed in the unified python group but was broken in python27 then I'll give it a shot.

[ben@…]

Ryan -

As suggested by you, I've modified as follows:

-- PortSystem 1.0 PortGroup python 1.0 python.version 27

name heapCL version 1.08.27 categories office www

license Apache supported_archs noarch description Command line tools for Heap CRM maintainers wbpsystems.com:ben

long_description HeapCL allows you to create messages, people, prospects and email templates from the command line. Why might you want to do this? Because if you have terminal access you can build this into an automation routine where otherwise you might need to hire a programmer.

extract.mkdir yes homepage ​http://heap.wbpsystems.com/cl.php master_sites ​https://crmondemand.biz/CL/

checksums rmd160 44c4acb31ca8491419a16a6ff94d13a64f66a460 \

sha256 cf04a961e5e7d6ce1bd68f9abafa9f6d6ed2aa0deee50f3664b73541c7b9ebd4

python.link_binaries_suffix

--

I've tested it and without the link line at the bottom, it doesn't allow the user to use the app unless they happen to be in the directory with all of the python files. I'd like to add the link back and disable the auto binary linking (because I'm not sure where it is linking to, but it isn't to the bin directory).

[jmroot (Joshua Root)]

The licensing situation is very unclear here. The only actual license header in the source is an MIT license, and the only reference to the Apache license is in the metadata in the setup.py. There are multiple versions of the Apache license, and there is no indication which one(s) are intended. If the code is in fact Apache licensed, not including the license text in the distribution is a violation of the license.

[ben@…]

Hi JMR -

I'm the owner of the code in heapCL and the setup file (and my position is that I don't care what the end user does with the code), since the poster library that I'm pulling in uses MIT, I've changed the portfile to say a MIT license. All I'm trying to do here is make installation easy for non-technical users.

[ben@…]

Updated portfile on Aug. 28th

[ben@…]

The newest attached portfile should take everyones concerns into account.

[pixilla (Bradley Giesbrecht)]

See r97232