loading checksums table from pre-checksum block?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

loading checksums table from pre-checksum block?

René J.V. Bertin
Hi,

I have a port with lots of subports for which I keep the checksums in a table-like structure in a dedicated file, so as to keep the Portfile a bit more manageable (and to be able to generate said table with a script when it's upgrade time).

Currently I have an explicit check that tests if the file exists in $filespath before sourcing it, to prevent errors when run from the registry.
Doing it from a pre-checksum block would be more elegant and more efficient, but I cannot seem to figure out how to get the `source` command to apply to the correct context.

How should I do that? I tried versions of the below with and without the quotes or the uplevel, none works:

{{{
pre-checksum {
    ui_debug "Reading checksums from ${filespath}/${checksums.table}"
    uplevel "source ${filespath}/${checksums.table}"
}
}}}

The checksums table file looks like this:

{{{
# checksums for foo family v5.47.0

array set checksumtable {
        # http://download.foo.org/stable/foo/5.47/foo1-5.47.0.tar.xz
        foo1 {
                e3a2f4e62d7ff76ff87479b322f3e8054e8f1dd2
                72a1962de852590d9494ebcfa9f98e1d394bad4680384b9a6937a7082140259e
        }
# many more of those
}
}}}

(the Portfile contains a procedure called from each subport that gets and sets the checksums for that subport.)

I could change the include file if needed but I'd prefer not to, unless there's a simple way to turn it into a true, pure datafile

Thanks,
R.
Reply | Threaded
Open this post in threaded view
|

Re: loading checksums table from pre-checksum block?

Rainer Müller-4
On 2018-10-27 09:16, René J.V. Bertin wrote:
> I have a port with lots of subports for which I keep the checksums in a table-like structure in a dedicated file, so as to keep the Portfile a bit more manageable (and to be able to generate said table with a script when it's upgrade time).
>
> Currently I have an explicit check that tests if the file exists in $filespath before sourcing it, to prevent errors when run from the registry.

Indeed, sourcing additional files is incompatible with storing the
Portfile in the registry. Don't do it.

> Doing it from a pre-checksum block would be more elegant and more efficient, but I cannot seem to figure out how to get the `source` command to apply to the correct context.
>
> How should I do that? I tried versions of the below with and without the quotes or the uplevel, none works:

pre-checksum would be run in a deeply nested context inside the port1.0
module. This is an implementation detail and Portfiles should not rely
on that. If you need to modify state outside of the proc, use a "global"
variable.

Rainer
Reply | Threaded
Open this post in threaded view
|

Re: loading checksums table from pre-checksum block?

Ryan Schmidt-24
In reply to this post by René J.V. Bertin


On Oct 27, 2018, at 02:16, René J.V. Bertin wrote:

> I have a port with lots of subports for which I keep the checksums in a table-like structure in a dedicated file, so as to keep the Portfile a bit more manageable (and to be able to generate said table with a script when it's upgrade time).

As Rainer said, sourcing a separate file into a Portfile is not supported. You can either set the checksums in the Portfile normally, or keep your table-like structure in the Portfile itself (which several other more complicated portfiles already do, such as qt5). Your script to automate upgrading this could either print out the new checksums directives or the table-like structure for you to manually copy into the Portfile, or it could find and replace the relevant section of the Portfile.

If each subport has distinct distfiles, it would be more straightforward to just put the checksums directive for that subport into the subport. If some subports share the same distfiles, then I could see the value of keeping each file's data in a table only once to avoid repeating it in several places.


> (the Portfile contains a procedure called from each subport that gets and sets the checksums for that subport.)

It is acceptable to list checksums for files a port does not use. So you could use a single checksums directive and list all files used by all subports, if that makes it easier.

Reply | Threaded
Open this post in threaded view
|

Re: loading checksums table from pre-checksum block?

Ryan Schmidt-24


On Oct 27, 2018, at 17:37, René J.V. Bertin wrote:

> No, I do not want to reintegrate the 60-some checksums into the portfile, I don't want to split it up and I don't want to rewrite my checksum generator script either. My question was how I can make the source command apply globally.
>
> Or if it's more politically correct, why doesn't the source command run in the global scope while it's perfectly possible to set variables in there - you don't even have to declare them global.
>
> What I'm doing isn't really all that different from how patchfiles work: those are also external files that aren't copied into the registry (last I looked, this morning) and there too this doesn't create issues because they're not used when running the copy from the registry.

MacPorts used to have an include statement, but it was removed in MacPorts 1.9.0 when we started storing Portfiles in the registry. If you want to see how it worked, you can look at the commit where it was removed:

https://trac.macports.org/changeset/68206

We could re-add it, or maybe change the source command to work how the include command used to work. But I'm not convinced that we should do that. There aren't many reasons why an include file would be useful, and we evidently haven't needed it for the past 8 years. Rainer used it in a few of his ports before it was removed; I don't think any other developers did.


Reply | Threaded
Open this post in threaded view
|

Re: loading checksums table from pre-checksum block?

Ken Cunningham

On 2018-10-27, at 3:52 PM, Ryan Schmidt wrote:

>
>
> On Oct 27, 2018, at 17:37, René J.V. Bertin wrote:
>
>> No, I do not want to reintegrate the 60-some checksums into the portfile, I don't want to split it up and I don't want to rewrite my checksum generator script either. My question was how I can make the source command apply globally.
>>
>> Or if it's more politically correct, why doesn't the source command run in the global scope while it's perfectly possible to set variables in there - you don't even have to declare them global.
>>
>> What I'm doing isn't really all that different from how patchfiles work: those are also external files that aren't copied into the registry (last I looked, this morning) and there too this doesn't create issues because they're not used when running the copy from the registry.
>
> MacPorts used to have an include statement, but it was removed in MacPorts 1.9.0 when we started storing Portfiles in the registry. If you want to see how it worked, you can look at the commit where it was removed:
>
> https://trac.macports.org/changeset/68206
>
> We could re-add it, or maybe change the source command to work how the include command used to work. But I'm not convinced that we should do that. There aren't many reasons why an include file would be useful, and we evidently haven't needed it for the past 8 years. Rainer used it in a few of his ports before it was removed; I don't think any other developers did.
>
>


I've written a few portfiles for my own use where i use "source" for simplicity --

like my libsdl2 for PPC port, for example, where I use a totally different Portfile for PPC than for Intel, and so I source the one I want to use (stored in the files dir) from a Portfile stub.

But so far there are always other ways around those tricks..

Ken





Reply | Threaded
Open this post in threaded view
|

Re: loading checksums table from pre-checksum block?

René J.V. Bertin
In reply to this post by Ryan Schmidt-24
On Saturday October 27 2018 17:52:15 Ryan Schmidt wrote:

>We could re-add it, or maybe change the source command to work how the include command used to work. But I'm not convinced that we should do that. There aren't many reasons why an include file would be useful, and we evidently haven't needed it for the past 8 years. Rainer used it in a few of his ports before it was removed; I don't think any other developers did.

No, I don't think there's much need for that, although I too have done what Ken describes (using different "implementation modules" instead of different sections in a single file). It's advanced usage, evidently, not needed in most situations, and I've stopped doing it because it always leads to error messages during de/activate and uninstall operations. Somehow they're never fatal, but I suppose that's a brittle situation that could break at any time.

As said, no such issues in the context where I'm using `source` here, and I don't mind putting some extra logic in this one Portfile (esp. since a pre- block can in principle be put at the very end of the file where it doesn't really hinder).

Maybe describe how to achieve this on the Recipes page, along with the other sometimes-useful tricks?

R.

PS: Oh, and don't do "conditional" PortGroup including, at least not if that PortGroup defines and sets a default variant. That's a great way to break behaviour in a way that can be very tricky to figure out. Don't ask me how I know :)


Reply | Threaded
Open this post in threaded view
|

Re: loading checksums table from pre-checksum block?

Ryan Schmidt-24


On Oct 28, 2018, at 03:39, René J.V. Bertin wrote:

> Maybe describe how to achieve this on the Recipes page, along with the other sometimes-useful tricks?

I don't think we want to publish a recipe on how to include files, because I don't think we want people to do it.

Reply | Threaded
Open this post in threaded view
|

Re: loading checksums table from pre-checksum block?

René J.V. Bertin
One way to make this easy and a priori trouble free is to modify the PortGroup command such files in $portdir or $filespath have priority over those int the normal PG directory (and don't advertise the new feature widely).

In fact I should look at how PGs are loaded and if they behave as expected when called from inside a pre- block.  I can't recall I ever tried that and off the top of my head I think they might run into the same problem I'm seeing.

R.