As a couple notes, I would add the following expansions to this.

...

...

"Allow the widest possible version range on any module, disallowing individual malfunctioning versions to further extend the range"

I think we are better off documenting bugs in misbehaving versions of modules and perhaps offering a module check utility rather than disallowing certain versions of modules.

How do you envisage the disallowing taking place? I was actually not thinking of actively disallowing specific versions, but rather document the fact that the module doesn't work with LedgerSMB by putting a version-exclusion in our cpanfile (the canonical location to declare version dependency).

Right and my point is that this is under inclusive since it is merely an install-time check

I don't understand. You want to replace an under-inclusive mechanism with an over-inclusive one? Why? I mean: if a user uses our under-inclusive mechanism, he or she gets a working install (presumably). With an over-inclusive mechanism there's much more room for problems.

and moreover lacks any forward knowledge of later possible breakage.

Well, when I say "known broken" then in fact it doesn't, because I don't claim that the list is complete either way (forward or backward). What I *do* claim is that the knowledge we do have is reflected in cpanfile. We could put it there in proze, but that doesn't help much as the rest of the file is intended to be machine-readable. Writing out knowledge in README.md doesn't make it machine-readable either and feels obfuscated too.

Also I can see possibilities where a package distributed under Debian or Gentoo might have a back ported fix and therefore it might also be over inclusive since there might be patched versions with the same version number which lack the misbehaviour.

Sure. But as you pointed out, the check is install-time only. And then even only when using a CPAN-tool (cpan, cpanm, cpan<whatever>). Package managers (dpkg, yum, ...) will not test these dependencies. So for a Debian or Ubuntu package, nothing happens when they have backported the fix and use the "declared unsupported" version-with-the-patch-which-makes-it-supported.

But if we do not document known mis-behaviour, how are packagers to find out about these incompatible versions?

I say this for two reasons:

...

...

1. Managing this list is annoying and deciding when to block a specific

version of a module is going to be an annoying and political decision, and

Well, so far I've explicitly excluded versions which were known to be buggy. E.g. there's a version of PGObject-Type-Bytestring which is known not to work with LedgerSMB, because I've fixed the bug that was exposed with you. My plan wasn't to go "hunt" for non-working versions.

What I would prefer would be a range of versions where the software was intended to work together and not make bugs in dependencies the responsibility of the LedgerSMB cpanfile at all.

Well, I don't think bugs in dependencies are the responsibility of LedgerSMB at all. What I do think though is that if we want the software to be used by people, we need to offer them a setup that works out of the box. Which means we need to do whatever we can to avoid people getting into our chat channel or mailing list saying "Your software doesn't work: I just spent 2 weeks getting it to work and there's just no way", where the answer is "Oh! But if you're using *that* version of module so-and-so, we could have told you in advance it wouldn't work...".

The reason again being that the bugs in the dependencies could conceivably be addressed in a number of different ways (patching the dependencies, possible by a packager, upgrading the dependencies, etc) and we have no knowledge of that.

Correct. And as soon as people don't use the vanilla versions, they're on their own. We could add documentation to the cpanfile why we exclude certain versions, though. That could help packagers decide whether or not the misbehaviour has been fixed in the version in their distribution.

What I still don't understand is if your opinion is that we should just let people struggle and if not what other mechanism you think we should use to "encode" our knowledge.

2. A block on a module version will not prevent someone who has an older

...

version of the module from upgrading to a blocked version since it is an install-time check and another piece of software could require a newer version and thus break the install-time check.

Yup. But it does help packagers and the cpanm installer when doing their work.

How does this affect back-porting of patches to otherwise stable dependencies?

Suppose for example there is a bug with some version of a common central dependency (say, something central like the Plack/CGI adaptors) that causes us grief, but Debian maintainers back port a fix for it. Do we disallow the patched version?

No, we disallow the original. If the person applying the patch does not change the version number, then there's no way we can know the difference, can we? But more importantly, the packager of *our* package can inspect the dependent packages and decide *not* to follow our dependency advice - assuming we include sufficient documentation as to why specific versions have been excluded.

Do we say "you cannot install from our source in this case?" I don't know what the answer is here. I don't even know if we want to make it our problem aside from support.

Maybe we could say that we only blacklist module versions in our direct control (like the PGObject stuff?)

Why is that any better than the "general module case"? Do we control packages in Debian not getting patched for PGObject?

So I would suggest deciding required versions by first-supported version

...

...

and up, and providing a tool or just documentation for checking for other problems in the mean time.

To what extent would that tool be different than 'cpanfile' and our dependencies test "xt/01.2-deps.t"? (It's in xt/ which could be a reason to develop an additional test for the actually installed versions...)

...

Secondly I would like to suggest that a focus on moving things to CPAN and breaking the application into components for better testability.

I'm all for breaking it up into components. However, I'm thinking that moving those components to CPAN is really only useful when the component has a function outside of LedgerSMB (i.e. is generic enough).

Certainly our reporting engine would be.

The formats, you mean, I take it? Or do you mean a broader scope? If it's the formats, I really wonder what they add on CPAN: as an example, after my refactoring on master, the LaTeX format is no more than 30 lines (less the escaping routine). But there's another thread waiting for that discussion. I'll respond in that thread.

Also a lot of tooling around LedgerSMB (such as what goes in the setup.pl) might be something we might want to break apart and have as a separate management apps supporting many stable versions. Our templating and mailer modules might be. And then the question becomes whether something like contact management is general enough to be modularised and spun off.

But my larger point here is that this generates some work for downstream packagers and we should also think about how to make this manageable there. I think we also want to think about the issues of spinning things off as a part of dependency management because at that point we are generating our own dependencies.

Yes, we have spun off our own dependency with PGObject as well. So, yes, I think that's a good thing to think about. My approach was that we think about it when we spin off the code that can be spun off; possibly we need to change the dependency declaration "rules" when we do. Currently though we don't have one and we're not spinning off more code today (are we?). So, my idea was to solve the problem that we're having today and when we want to make things more complex tomorrow, then we solve the added complexity in its full breadth (meaning including dependency management).

"Require as few a possible modules in the expanded dependency tree

...

...

(prefer modules as direct dependencies which are already depended on implicitly)"

Additionally I think that when we spin things off we should shoot for modules which are simple in interface, within a year or two will likely be pretty close to bug free and unlikely to require dramatic modifications, and therefore keep spin-offs throttled so they do not cause undue chaos for packagers.

The reason to put this point into the policy is actually not mainly for packagers (although, as you note, it does help). The main reason to put it there is to support those installing from source. The current dependency list for LedgerSMB is huge. This doesn't mean it shouldn't grow new dependencies, but my point here is that if we can - sometimes even significantly - reduce the dependency tree by being careful about which immediate dependencies we choose.

This actually brings me to a reason we may want to be thinking about pushing as much off (eventually) into external dependencies as we can.

Right now we have a huge direct dependency tree. This is a problem for a number of reasons. It makes it hard for people to install from source. It also creates a whole lot of extra work for packagers.

Is our dependency tree in general a problem? Or the fact that we have a huge *direct* dependency tree?

For example when creating the Gentoo overlay I am expecting the vast majority of my time to be managing and testing our dependency tree. Packaging the dependencies is no problem. Making sure I have all of them and that they all work as expected. That's the problem.

But doesn't that problem remain when you make the dependency tree a little bit more indirect by splitting off the mailer? I mean, the mailer still has the original dependencies, we now depend on the new mailer, so, all in all we added 1 more dependency to manage, right?

But now, imagine that we could take the reporting and template libraries and spin them off. How many dependencies could we push to indirect by doing so? How much easier would it be to test installation of optional capabilities? By my count we could reduce direct dependencies by at least 2 and optional dependencies by 4 or 6 depending on how we do it. If we spin off the reporting engine as a whole we could perhaps reduce dependencies long-term by at least 10 (4 standard and 6 optional).

I'm less optimistic there, because I'm assuming that at least for a number of years to come, we'll be the only ones depending on those intermediate dependencies, which means we basically just added complexity to the mix.

" Not depend directly on modules which have overlapping functionalities"

...

...

Big caveat here is that some modules that are used *because* they are overlapping might be in a different position. Moo/Moose is a good example and both are widely used enough that there is no harm in using Moo instead of Moose in spun-off modules. However we still have some old paradigms in the code that need to be cleaned up and we should also focus on this.

Well, the point about "depend directly" is that our tree either depends on Moose *or* on Moo, but not both. Whether or not our dependencies themselves depend on the other of the two, is up to our dependencies, of course.

If we incubate modules we are spinning off, we may want to depend on Moo and Moose temporarily because the justification for adding Moose to a spun-off dependency I going to be a bit higher than Moo.

Fair enough. While the policy in my opinion should be taken seriously, I also think that we should still allow ourselves to be reasonable. This is a case where I think the policy should probably be suspended for a certain period of time. I'm thinking that we'd need to discuss that here on a case-by-case basis in order not to become too hand-wavy with the policy.

"Not require modules which only provide nice-to-have functionality"

...

...

Also, while I am happy to see optional modules used to provide nice-to-have functionality it is worth noting that there are two things that need to be guarded against here. The first are extra dependencies. The second is extra code complexity that comes with adding such options. I would say that both need to be justified before we should allow them and where we do allow them we should think about how to set up proper interfaces so we don't have lots of conditional module handling everywhere.

Ok. This is a broader point than our dependency management. I think this is a point to be put in the category "what should we consider when thinking about adding new features/functionalities?"

...

"Group feature dependencies into their respective features as much as possible (so as to not require them for a more basic installation)"

A corollary here might be that long-run a lot of the application today should be relegated to optional features as we go forward. If someone doesn't need inventory tracking, why install it? If one doesn't need more than GL, customers, vendors, and basic reporting, why install more than that?

Yup. That does work. Personally I think that installing inventory tracking (if it doesn't add many new dependencies), shouldn't be a big problem; we're in the terabyte era and installing one such feature is just a few (hundred) kilobyte. Also, having the feature installed might actually reduce code complexity. However, being able *not* to install the feature would seem to require some infrastructure to create, install and register components. Which might work out great for (third-party) components which are yet to be written.

...

Of course we aren't there yet but I would suggest that a forward-thinking view of dependencies we might want to think about it not only regarding the dependency problems we encounter with maintaining and working on the current code but also in the question of how modularised and loosely coupled we may want the code to be in the future.

My approach here has been to put the problem of dependency declaration in a system with loosely coupled components is to be part of a design of such a module system; that is, for now, I haven't been looking too far into the future and trying to make the best out of the current situation for current package managers and installers-from-source. The immediate trigger for my previous mail was a discussion on #ledgersmb with Yves and David about the fact that Yves declared the minimum version of PGObject to be 2.0.2. I'm against requiring such a new version as the bare minimum since the code base supports anything at or newer than 1.403.2. Hence my idea about requiring a policy with a solid reasoning of why we do things the way we do. Then we also have a good foundation to evaluate the minimum PGObject version requirement.

Agreed. I am not even sure we should blacklist versions just because they are broken on CPAN because there could be patched versions packaged in distros. Mere warnings in logs is not enough to bump a version.

Right. I'm not saying we should be checking the version on each request or even on each Starman start-up. I'm restricting it completely to installation time and package-time documentation (but machine-readable).

Looking at the cpanfile, it appears to be the common practice however because apparently blacklisting individual versions doesn't work. See the following lines:

# cpanm doesn't handle our true dependency declaration correctly:

# PGObject::Simple 3.0.1 breaks our file uploads

#requires 'PGObject::Simple', '>=2.0.0, !=3.0.0, !=3.0.1';

#requires 'PGObject::Simple::Role', '1.13.2';

# so we use:

requires 'PGObject::Simple', '3.0.2';

requires 'PGObject::Simple::Role', '2.0.0';

I think we would do better to require PGObject::Simple 2.0.0 and up and leave it to packagers to deal with the 3.0.0/3.0.1 breakage for example.

The reason that's there the way it is, is because we test with Travis CI and we let Travis CI handle the dependency tree setup completely by way of cpanm. If we were to force-install 3.0.2 before running the rest of the dependency installation or we'd manage the complete dependency tree ourselves - as a packager would - then we can return to the commented-out require statements. In other words, it's the fact that cpanfile is overloaded in the CI process which causes the commented lines to be commented. Ideally, we manage the installation of dependencies of TravisCI ourselves (at least partially); then I can remove the work-around lines and uncomment the original lines.

Thanks for your response! I think it's good to have this discussion in order to have a common understanding of what our respective expectations and goals are.

On Mon, Aug 28, 2017 at 11:30 PM, Erik Huelsmann ehuels@gmail.com wrote:

As a couple notes, I would add the following expansions to this.

...

...

...

"Allow the widest possible version range on any module, disallowing individual malfunctioning versions to further extend the range"

I think we are better off documenting bugs in misbehaving versions of modules and perhaps offering a module check utility rather than disallowing certain versions of modules.

How do you envisage the disallowing taking place? I was actually not thinking of actively disallowing specific versions, but rather document the fact that the module doesn't work with LedgerSMB by putting a version-exclusion in our cpanfile (the canonical location to declare version dependency).

Right and my point is that this is under inclusive since it is merely an install-time check

I don't understand. You want to replace an under-inclusive mechanism with an over-inclusive one? Why? I mean: if a user uses our under-inclusive mechanism, he or she gets a working install (presumably). With an over-inclusive mechanism there's much more room for problems.

...

and moreover lacks any forward knowledge of later possible breakage.

Well, when I say "known broken" then in fact it doesn't, because I don't claim that the list is complete either way (forward or backward). What I *do* claim is that the knowledge we do have is reflected in cpanfile. We could put it there in proze, but that doesn't help much as the rest of the file is intended to be machine-readable. Writing out knowledge in README.md doesn't make it machine-readable either and feels obfuscated too.

...

Also I can see possibilities where a package distributed under Debian or Gentoo might have a back ported fix and therefore it might also be over inclusive since there might be patched versions with the same version number which lack the misbehaviour.

Sure. But as you pointed out, the check is install-time only. And then even only when using a CPAN-tool (cpan, cpanm, cpan<whatever>). Package managers (dpkg, yum, ...) will not test these dependencies. So for a Debian or Ubuntu package, nothing happens when they have backported the fix and use the "declared unsupported" version-with-the-patch-which- makes-it-supported.

But if we do not document known mis-behaviour, how are packagers to find out about these incompatible versions?

...

I say this for two reasons:

...

...

1. Managing this list is annoying and deciding when to block a

specific version of a module is going to be an annoying and political decision, and

Well, so far I've explicitly excluded versions which were known to be buggy. E.g. there's a version of PGObject-Type-Bytestring which is known not to work with LedgerSMB, because I've fixed the bug that was exposed with you. My plan wasn't to go "hunt" for non-working versions.

What I would prefer would be a range of versions where the software was intended to work together and not make bugs in dependencies the responsibility of the LedgerSMB cpanfile at all.

Well, I don't think bugs in dependencies are the responsibility of LedgerSMB at all. What I do think though is that if we want the software to be used by people, we need to offer them a setup that works out of the box. Which means we need to do whatever we can to avoid people getting into our chat channel or mailing list saying "Your software doesn't work: I just spent 2 weeks getting it to work and there's just no way", where the answer is "Oh! But if you're using *that* version of module so-and-so, we could have told you in advance it wouldn't work...".

...

The reason again being that the bugs in the dependencies could conceivably be addressed in a number of different ways (patching the dependencies, possible by a packager, upgrading the dependencies, etc) and we have no knowledge of that.

Correct. And as soon as people don't use the vanilla versions, they're on their own. We could add documentation to the cpanfile why we exclude certain versions, though. That could help packagers decide whether or not the misbehaviour has been fixed in the version in their distribution.

What I still don't understand is if your opinion is that we should just let people struggle and if not what other mechanism you think we should use to "encode" our knowledge.

2. A block on a module version will not prevent someone who has an older

...

...

version of the module from upgrading to a blocked version since it is an install-time check and another piece of software could require a newer version and thus break the install-time check.

Yup. But it does help packagers and the cpanm installer when doing their work.

How does this affect back-porting of patches to otherwise stable dependencies?

Suppose for example there is a bug with some version of a common central dependency (say, something central like the Plack/CGI adaptors) that causes us grief, but Debian maintainers back port a fix for it. Do we disallow the patched version?

No, we disallow the original. If the person applying the patch does not change the version number, then there's no way we can know the difference, can we? But more importantly, the packager of *our* package can inspect the dependent packages and decide *not* to follow our dependency advice - assuming we include sufficient documentation as to why specific versions have been excluded.

...

Do we say "you cannot install from our source in this case?" I don't know what the answer is here. I don't even know if we want to make it our problem aside from support.

Maybe we could say that we only blacklist module versions in our direct control (like the PGObject stuff?)

Why is that any better than the "general module case"? Do we control packages in Debian not getting patched for PGObject?

...

So I would suggest deciding required versions by first-supported version

...

...

and up, and providing a tool or just documentation for checking for other problems in the mean time.

To what extent would that tool be different than 'cpanfile' and our dependencies test "xt/01.2-deps.t"? (It's in xt/ which could be a reason to develop an additional test for the actually installed versions...)

...

Secondly I would like to suggest that a focus on moving things to CPAN and breaking the application into components for better testability.

I'm all for breaking it up into components. However, I'm thinking that moving those components to CPAN is really only useful when the component has a function outside of LedgerSMB (i.e. is generic enough).

Certainly our reporting engine would be.

The formats, you mean, I take it? Or do you mean a broader scope? If it's the formats, I really wonder what they add on CPAN: as an example, after my refactoring on master, the LaTeX format is no more than 30 lines (less the escaping routine). But there's another thread waiting for that discussion. I'll respond in that thread.

...

Also a lot of tooling around LedgerSMB (such as what goes in the setup.pl) might be something we might want to break apart and have as a separate management apps supporting many stable versions. Our templating and mailer modules might be. And then the question becomes whether something like contact management is general enough to be modularised and spun off.

But my larger point here is that this generates some work for downstream packagers and we should also think about how to make this manageable there. I think we also want to think about the issues of spinning things off as a part of dependency management because at that point we are generating our own dependencies.

Yes, we have spun off our own dependency with PGObject as well. So, yes, I think that's a good thing to think about. My approach was that we think about it when we spin off the code that can be spun off; possibly we need to change the dependency declaration "rules" when we do. Currently though we don't have one and we're not spinning off more code today (are we?). So, my idea was to solve the problem that we're having today and when we want to make things more complex tomorrow, then we solve the added complexity in its full breadth (meaning including dependency management).

...

"Require as few a possible modules in the expanded dependency tree

...

...

(prefer modules as direct dependencies which are already depended on implicitly)"

Additionally I think that when we spin things off we should shoot for modules which are simple in interface, within a year or two will likely be pretty close to bug free and unlikely to require dramatic modifications, and therefore keep spin-offs throttled so they do not cause undue chaos for packagers.

The reason to put this point into the policy is actually not mainly for packagers (although, as you note, it does help). The main reason to put it there is to support those installing from source. The current dependency list for LedgerSMB is huge. This doesn't mean it shouldn't grow new dependencies, but my point here is that if we can - sometimes even significantly - reduce the dependency tree by being careful about which immediate dependencies we choose.

This actually brings me to a reason we may want to be thinking about pushing as much off (eventually) into external dependencies as we can.

Right now we have a huge direct dependency tree. This is a problem for a number of reasons. It makes it hard for people to install from source. It also creates a whole lot of extra work for packagers.

Is our dependency tree in general a problem? Or the fact that we have a huge *direct* dependency tree?

...

For example when creating the Gentoo overlay I am expecting the vast majority of my time to be managing and testing our dependency tree. Packaging the dependencies is no problem. Making sure I have all of them and that they all work as expected. That's the problem.

But doesn't that problem remain when you make the dependency tree a little bit more indirect by splitting off the mailer? I mean, the mailer still has the original dependencies, we now depend on the new mailer, so, all in all we added 1 more dependency to manage, right?

...

But now, imagine that we could take the reporting and template libraries and spin them off. How many dependencies could we push to indirect by doing so? How much easier would it be to test installation of optional capabilities? By my count we could reduce direct dependencies by at least 2 and optional dependencies by 4 or 6 depending on how we do it. If we spin off the reporting engine as a whole we could perhaps reduce dependencies long-term by at least 10 (4 standard and 6 optional).

I'm less optimistic there, because I'm assuming that at least for a number of years to come, we'll be the only ones depending on those intermediate dependencies, which means we basically just added complexity to the mix.

...

" Not depend directly on modules which have overlapping functionalities"

...

...

Big caveat here is that some modules that are used *because* they are overlapping might be in a different position. Moo/Moose is a good example and both are widely used enough that there is no harm in using Moo instead of Moose in spun-off modules. However we still have some old paradigms in the code that need to be cleaned up and we should also focus on this.

Well, the point about "depend directly" is that our tree either depends on Moose *or* on Moo, but not both. Whether or not our dependencies themselves depend on the other of the two, is up to our dependencies, of course.

If we incubate modules we are spinning off, we may want to depend on Moo and Moose temporarily because the justification for adding Moose to a spun-off dependency I going to be a bit higher than Moo.

Fair enough. While the policy in my opinion should be taken seriously, I also think that we should still allow ourselves to be reasonable. This is a case where I think the policy should probably be suspended for a certain period of time. I'm thinking that we'd need to discuss that here on a case-by-case basis in order not to become too hand-wavy with the policy.

...

"Not require modules which only provide nice-to-have functionality"

...

...

Also, while I am happy to see optional modules used to provide nice-to-have functionality it is worth noting that there are two things that need to be guarded against here. The first are extra dependencies. The second is extra code complexity that comes with adding such options. I would say that both need to be justified before we should allow them and where we do allow them we should think about how to set up proper interfaces so we don't have lots of conditional module handling everywhere.

Ok. This is a broader point than our dependency management. I think this is a point to be put in the category "what should we consider when thinking about adding new features/functionalities?"

...

"Group feature dependencies into their respective features as much as possible (so as to not require them for a more basic installation)"

A corollary here might be that long-run a lot of the application today should be relegated to optional features as we go forward. If someone doesn't need inventory tracking, why install it? If one doesn't need more than GL, customers, vendors, and basic reporting, why install more than that?

Yup. That does work. Personally I think that installing inventory tracking (if it doesn't add many new dependencies), shouldn't be a big problem; we're in the terabyte era and installing one such feature is just a few (hundred) kilobyte. Also, having the feature installed might actually reduce code complexity. However, being able *not* to install the feature would seem to require some infrastructure to create, install and register components. Which might work out great for (third-party) components which are yet to be written.

...

Of course we aren't there yet but I would suggest that a forward-thinking view of dependencies we might want to think about it not only regarding the dependency problems we encounter with maintaining and working on the current code but also in the question of how modularised and loosely coupled we may want the code to be in the future.

My approach here has been to put the problem of dependency declaration in a system with loosely coupled components is to be part of a design of such a module system; that is, for now, I haven't been looking too far into the future and trying to make the best out of the current situation for current package managers and installers-from-source. The immediate trigger for my previous mail was a discussion on #ledgersmb with Yves and David about the fact that Yves declared the minimum version of PGObject to be 2.0.2. I'm against requiring such a new version as the bare minimum since the code base supports anything at or newer than 1.403.2. Hence my idea about requiring a policy with a solid reasoning of why we do things the way we do. Then we also have a good foundation to evaluate the minimum PGObject version requirement.

Agreed. I am not even sure we should blacklist versions just because they are broken on CPAN because there could be patched versions packaged in distros. Mere warnings in logs is not enough to bump a version.

Right. I'm not saying we should be checking the version on each request or even on each Starman start-up. I'm restricting it completely to installation time and package-time documentation (but machine-readable).

...

Looking at the cpanfile, it appears to be the common practice however because apparently blacklisting individual versions doesn't work. See the following lines:

# cpanm doesn't handle our true dependency declaration correctly:

# PGObject::Simple 3.0.1 breaks our file uploads

#requires 'PGObject::Simple', '>=2.0.0, !=3.0.0, !=3.0.1';

#requires 'PGObject::Simple::Role', '1.13.2';

# so we use:

requires 'PGObject::Simple', '3.0.2';

requires 'PGObject::Simple::Role', '2.0.0';

I think we would do better to require PGObject::Simple 2.0.0 and up and leave it to packagers to deal with the 3.0.0/3.0.1 breakage for example.

The reason that's there the way it is, is because we test with Travis CI and we let Travis CI handle the dependency tree setup completely by way of cpanm. If we were to force-install 3.0.2 before running the rest of the dependency installation or we'd manage the complete dependency tree ourselves - as a packager would - then we can return to the commented-out require statements. In other words, it's the fact that cpanfile is overloaded in the CI process which causes the commented lines to be commented. Ideally, we manage the installation of dependencies of TravisCI ourselves (at least partially); then I can remove the work-around lines and uncomment the original lines.

You know we could test for environment variables and set it differently on Travis.

Thanks for your response! I think it's good to have this discussion in order to have a common understanding of what our respective expectations and goals are.

-- Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

On Tue, Aug 29, 2017 at 6:51 AM, David G lsmbdev@sbts.com.au wrote:

Hi Chris,

On 28/08/17 15:57, Chris Travers wrote:

On Sun, Aug 27, 2017 at 11:52 PM, Erik Huelsmann ehuels@gmail.com wrote:

...

Hi,

Thanks for the feedback.

On Sun, Aug 27, 2017 at 12:56 PM, Chris Travers chris.travers@gmail.com wrote:

...

As a couple notes, I would add the following expansions to this.

"Allow the widest possible version range on any module, disallowing individual malfunctioning versions to further extend the range"

I think we are better off documenting bugs in misbehaving versions of modules and perhaps offering a module check utility rather than disallowing certain versions of modules.

How do you envisage the disallowing taking place? I was actually not thinking of actively disallowing specific versions, but rather document the fact that the module doesn't work with LedgerSMB by putting a version-exclusion in our cpanfile (the canonical location to declare version dependency).

Right and my point is that this is under inclusive since it is merely an install-time check and moreover lacks any forward knowledge of later possible breakage. Also I can see possibilities where a package distributed under Debian or Gentoo might have a back ported fix and therefore it might also be over inclusive since there might be patched versions with the same version number which lack the misbehaviour.

If a patched version retains exactly the same version number, then I'd consider that to be a bug in the patch. There should be at least a suffix indicating it's patched, unless the patch is simply a change to conform with distro policy, such as a different path, or change in a library name etc. As Erik says in his response, I don't think we need to concern ourselves too much with dependencies on packaged installs, that's up to the packager (with our support as needed during packaging)

Two points: 1. Please correct me if I am wrong but I don't think Debian packages change the version $VERSION when they back port fixes. 2. This is a specific problem when installing LedgerSMB from source and packages from the distribution. I assume we want to support that.

Now assuming I am right on point 1, an important question is whether we want to take on the responsibility in the cpanfile for knowing what every distro we support has done in that area. I would ague that maybe we don't and therefore maybe the cpanfile should presume that patched versions of broken dependencies exist and we should just say "not our problem" aside from user support. How the user and the user's source of the package goes about fixing the bug then becomes something we don't have to know how it works or worry about.

...

...

I say this for two reasons:

1. Managing this list is annoying and deciding when to block a specific

version of a module is going to be an annoying and political decision, and

Well, so far I've explicitly excluded versions which were known to be buggy. E.g. there's a version of PGObject-Type-Bytestring which is known not to work with LedgerSMB, because I've fixed the bug that was exposed with you. My plan wasn't to go "hunt" for non-working versions.

What I would prefer would be a range of versions where the software was intended to work together and not make bugs in dependencies the responsibility of the LedgerSMB cpanfile at all. The reason again being that the bugs in the dependencies could conceivably be addressed in a number of different ways (patching the dependencies, possible by a packager, upgrading the dependencies, etc) and we have no knowledge of that.

...

...

2. A block on a module version will not prevent someone who has an

older version of the module from upgrading to a blocked version since it is an install-time check and another piece of software could require a newer version and thus break the install-time check.

Yup. But it does help packagers and the cpanm installer when doing their work.

How does this affect back-porting of patches to otherwise stable dependencies?

Suppose for example there is a bug with some version of a common central dependency (say, something central like the Plack/CGI adaptors) that causes us grief, but Debian maintainers back port a fix for it. Do we disallow the patched version? Do we say "you cannot install from our source in this case?" I don't know what the answer is here. I don't even know if we want to make it our problem aside from support.

Maybe we could say that we only blacklist module versions in our direct control (like the PGObject stuff?)

...

...

So I would suggest deciding required versions by first-supported version and up, and providing a tool or just documentation for checking for other problems in the mean time.

To what extent would that tool be different than 'cpanfile' and our dependencies test "xt/01.2-deps.t"? (It's in xt/ which could be a reason to develop an additional test for the actually installed versions...)

...

Secondly I would like to suggest that a focus on moving things to CPAN and breaking the application into components for better testability.

I'm all for breaking it up into components. However, I'm thinking that moving those components to CPAN is really only useful when the component has a function outside of LedgerSMB (i.e. is generic enough).

Certainly our reporting engine would be. Also a lot of tooling around LedgerSMB (such as what goes in the setup.pl) might be something we might want to break apart and have as a separate management apps supporting many stable versions. Our templating and mailer modules might be. And then the question becomes whether something like contact management is general enough to be modularised and spun off.

But my larger point here is that this generates some work for downstream packagers and we should also think about how to make this manageable there. I think we also want to think about the issues of spinning things off as a part of dependency management because at that point we are generating our own dependencies.

...

...

"Require as few a possible modules in the expanded dependency tree (prefer modules as direct dependencies which are already depended on implicitly)"

Additionally I think that when we spin things off we should shoot for modules which are simple in interface, within a year or two will likely be pretty close to bug free and unlikely to require dramatic modifications, and therefore keep spin-offs throttled so they do not cause undue chaos for packagers.

The reason to put this point into the policy is actually not mainly for packagers (although, as you note, it does help). The main reason to put it there is to support those installing from source. The current dependency list for LedgerSMB is huge. This doesn't mean it shouldn't grow new dependencies, but my point here is that if we can - sometimes even significantly - reduce the dependency tree by being careful about which immediate dependencies we choose.

This actually brings me to a reason we may want to be thinking about pushing as much off (eventually) into external dependencies as we can.

Right now we have a huge direct dependency tree. This is a problem for a number of reasons. It makes it hard for people to install from source. It also creates a whole lot of extra work for packagers. For example when creating the Gentoo overlay I am expecting the vast majority of my time to be managing and testing our dependency tree. Packaging the dependencies is no problem. Making sure I have all of them and that they all work as expected. That's the problem.

But now, imagine that we could take the reporting and template libraries and spin them off. How many dependencies could we push to indirect by doing so? How much easier would it be to test installation of optional capabilities? By my count we could reduce direct dependencies by at least 2 and optional dependencies by 4 or 6 depending on how we do it. If we spin off the reporting engine as a whole we could perhaps reduce dependencies long-term by at least 10 (4 standard and 6 optional).

Honestly, I don't see how spinning parts of our code out into separate cpan modules will help the dependency tree at all. We still have the same tree, it's then just distributed among many modules, which will each have an overlapping tree. Worse, is the fact that the tree that needs to be met is now harder to discover, as you need to check each of the modules for what's required.

It's not the same tree though. It is more modular and easy to test, and the responsibility for change is more clearly defined. My view is that smaller pieces of software, with stable contracts between them, are easier to manage, test, and so forth than bigger pieces of software with more fluid internal contracts. Put another way (and this may be a philosophical difference here): small, well-defined responsibilities are easier to keep than big, nebulous ones. Pieces of software should have small, well defined responsibilities in my view. The thing is, indirect dependencies are not our responsibility so pushing more things to indirect dependencies makes our responsibility narrower, better defined, and ultimately easier to keep.

The idea of spinning off the templates is actually an important case in point.

The specific modules I would suggest we look at in the near future are the templates and the reporting engine (and actually I have immediate uses for these outside of LedgerSMB bit inside the LedgerSMB ecosystem).

Now if we were to have the template system outside, then we have two required modules (the successors to LedgerSMB::Template, probably, the successor to LedgerSMB::Template::HTML) which are now required. Assuming that this successor has a good plugin framework and we can auto-detect any other template library we put in, we can effectively that the LedgerSMB application no longer has any responsibility to the PDF, OpenOffice, CSV, etc. generation. If someone wants to generate spreadsheets, they do:

cpan App::LedgerSMB::Template::Plugin::OpenOffice;

And away they go. We no longer worry about what dependencies this has. It is not LedgerSMB's (the software) responsibility at all. The template engine would have to have a plugin structure that probably couldn't change much, and an interface for interacting with plugins that could not change. But this is not actually a big difficulty in that case.

For pre packaged modules that's only a problem for the packager, but for git or tgz installs it's a problem for the installer. The installer of a src version then also needs to download and install many individual modules. Development installs will become harder, especially if different versions of a module are needed for different branches being worked on.

Finally, it will add additional load to our packagers. Right now Jame has quite a large number of perl packages that he deals with simply to support LedgerSMB being packaged. That can lead to delays in packaging a new LedgerSMB release if there are also changes to it's dependencies . Having even more separate dependencies will only make that worse.

I think this is actually a very valid concern. There are two very important ways we can help with that:

1. we don't release a lot of new spin-offs until the old ones are really stable and we are guaranteeing compatibility for a while. If Debian has an old version of PGObject, as long as we support that interface...

2. we make sure we have stable interfaces before we spin things off.

...

...

" Not depend directly on modules which have overlapping functionalities"

Big caveat here is that some modules that are used *because* they are overlapping might be in a different position. Moo/Moose is a good example and both are widely used enough that there is no harm in using Moo instead of Moose in spun-off modules. However we still have some old paradigms in the code that need to be cleaned up and we should also focus on this.

Well, the point about "depend directly" is that our tree either depends on Moose *or* on Moo, but not both. Whether or not our dependencies themselves depend on the other of the two, is up to our dependencies, of course.

If we incubate modules we are spinning off, we may want to depend on Moo and Moose temporarily because the justification for adding Moose to a spun-off dependency I going to be a bit higher than Moo.

...

...

"Not require modules which only provide nice-to-have functionality"

Also, while I am happy to see optional modules used to provide nice-to-have functionality it is worth noting that there are two things that need to be guarded against here. The first are extra dependencies. The second is extra code complexity that comes with adding such options. I would say that both need to be justified before we should allow them and where we do allow them we should think about how to set up proper interfaces so we don't have lots of conditional module handling everywhere.

Ok. This is a broader point than our dependency management. I think this is a point to be put in the category "what should we consider when thinking about adding new features/functionalities?"

...

"Group feature dependencies into their respective features as much as possible (so as to not require them for a more basic installation)"

A corollary here might be that long-run a lot of the application today should be relegated to optional features as we go forward. If someone doesn't need inventory tracking, why install it? If one doesn't need more than GL, customers, vendors, and basic reporting, why install more than that?

Yup. That does work. Personally I think that installing inventory tracking (if it doesn't add many new dependencies), shouldn't be a big problem; we're in the terabyte era and installing one such feature is just a few (hundred) kilobyte. Also, having the feature installed might actually reduce code complexity. However, being able *not* to install the feature would seem to require some infrastructure to create, install and register components. Which might work out great for (third-party) components which are yet to be written.

...

Of course we aren't there yet but I would suggest that a forward-thinking view of dependencies we might want to think about it not only regarding the dependency problems we encounter with maintaining and working on the current code but also in the question of how modularised and loosely coupled we may want the code to be in the future.

My approach here has been to put the problem of dependency declaration in a system with loosely coupled components is to be part of a design of such a module system; that is, for now, I haven't been looking too far into the future and trying to make the best out of the current situation for current package managers and installers-from-source. The immediate trigger for my previous mail was a discussion on #ledgersmb with Yves and David about the fact that Yves declared the minimum version of PGObject to be 2.0.2. I'm against requiring such a new version as the bare minimum since the code base supports anything at or newer than 1.403.2. Hence my idea about requiring a policy with a solid reasoning of why we do things the way we do. Then we also have a good foundation to evaluate the minimum PGObject version requirement.

Agreed. I am not even sure we should blacklist versions just because they are broken on CPAN because there could be patched versions packaged in distros. Mere warnings in logs is not enough to bump a version.

As said previously, I don't think we need to concern ourselves with patched (same version number) versions, as it shouldn't happen (the version number should gain a suffix) and it's up to the packagers to handle version compatibility anyway. They are certainly better positioned to know if an available package has been patched.

But that is the package suffix, not the $VERSION right? On delian-based systems I have worked on I have *never* seen a suffix on internal version numbers, only on package versions. Maybe I am missing something?

Also, as long as we are only (under normal conditions) doing version checks in cpanfile, it shouldn't be a real problem for packaged installs.

Looking at the cpanfile, it appears to be the common practice however because apparently blacklisting individual versions doesn't work. See the following lines:

# cpanm doesn't handle our true dependency declaration correctly:

# PGObject::Simple 3.0.1 breaks our file uploads

#requires 'PGObject::Simple', '>=2.0.0, !=3.0.0, !=3.0.1';

#requires 'PGObject::Simple::Role', '1.13.2';

# so we use:

requires 'PGObject::Simple', '3.0.2';

requires 'PGObject::Simple::Role', '2.0.0';

I think we would do better to require PGObject::Simple 2.0.0 and up and leave it to packagers to deal with the 3.0.0/3.0.1 breakage for example.

...

...

Best Wishes, Chris Travers

Regards,

-- Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

-- Best Wishes, Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in. http://www.efficito.com/learn_more

---

devel mailing listdevel@lists.ledgersmb.orghttps://lists.ledgersmb.org/mailman/listinfo/devel

---

devel mailing list devel@lists.ledgersmb.org https://lists.ledgersmb.org/mailman/listinfo/devel

Ok so I was thinking about this last night and it occurred to me that our problem, really, isn't a "broken module" problem but something else.

Erik's proposed policy has my full support as a stop-gap measure. But I have some serious long-term concerns if we don't have the deeper issue resolved.

On Wed, Aug 30, 2017 at 11:08 PM, Erik Huelsmann ehuels@gmail.com wrote:

As a couple notes, I would add the following expansions to this.

...

...

...

...

"Allow the widest possible version range on any module, disallowing individual malfunctioning versions to further extend the range"

I think we are better off documenting bugs in misbehaving versions of modules and perhaps offering a module check utility rather than disallowing certain versions of modules.

How do you envisage the disallowing taking place? I was actually not thinking of actively disallowing specific versions, but rather document the fact that the module doesn't work with LedgerSMB by putting a version-exclusion in our cpanfile (the canonical location to declare version dependency).

Right and my point is that this is under inclusive since it is merely an install-time check and moreover lacks any forward knowledge of later possible breakage. Also I can see possibilities where a package distributed under Debian or Gentoo might have a back ported fix and therefore it might also be over inclusive since there might be patched versions with the same version number which lack the misbehaviour.

If a patched version retains exactly the same version number, then I'd consider that to be a bug in the patch. There should be at least a suffix indicating it's patched, unless the patch is simply a change to conform with distro policy, such as a different path, or change in a library name etc. As Erik says in his response, I don't think we need to concern ourselves too much with dependencies on packaged installs, that's up to the packager (with our support as needed during packaging)

Two points:

1. Please correct me if I am wrong but I don't think Debian packages

change the version $VERSION when they back port fixes.

That's very well possible, yes.

...

2. This is a specific problem when installing LedgerSMB from source and

packages from the distribution. I assume we want to support that.

Well, yes and no. Ideally, we don't need to support this combination, because we provide packages (at least for the most popular of distributions). I see installing from source with packages from the dist as a workaround for packages not being available or sufficiently up to date.

But with Debian's support cycle policies I don't see an easy way out of that. You will always see someone who wants a few latest-generation apps on Debian stable and back ports may or may not be current enough. I think, long-run, deciding our dependencies based on what versions are in particular distributions is going to be a mess. Short-run though it may be our best shot.

...

Now assuming I am right on point 1, an important question is whether we want to take on the responsibility in the cpanfile for knowing what every distro we support has done in that area.

The answer to this point - from me at least - is a firm No. People can install most packages from their distro, but if some have been blocked by us due to version mismatch, they'll have to accept that if they don't install manually for the remaining packages, `cpanm` is going to upgrade the packages which have mismatched versions. By consequence they'll need something like "local::lib".

The obvious question then is why we accept older versions of PGObject while blacklisting some but not all version numbers of PGObject::Simple. Obviously we want working software. It seems the answer is "that's the best we can do right now." However, such a line makes me uncomfortable because it seems like we are saying that we require that it works with the version on CPAN, but will bend over backwards just a little for the sake of a few popular distributions (I assume we would not do the same if we were talking about a more current version in Debian and an older version in, say, OpenSuSE).

So let's accept that this is the best we can do for now but I want to say I see the situation as posing some problems that I think should be on our radar. So I would like to see what we can do to sanely remove the blacklists.

...

I would ague that maybe we don't and therefore maybe the cpanfile should presume that patched versions of broken dependencies exist and we should just say "not our problem" aside from user support.

Ah. But the "not our problem" can be taken two directions: over-inclusive at install-time (your solution, as I understand it), which results in non-working installations or under-inclusive at install-time (what I advocate) which results in unnecessary upgrades but is much more likely to result in working installs. My interpretation of "not our problem" is: it's not our problem that packagers don't change their version numbers (be it for good reasons or not) -- which means that we have to reject packages which *might* have been acceptable.

I don't think it is the job of dependency management (In an ideal world) to ensure bug-free dependencies. I think we should strive for "these are intended to work together" from the cpanfile and leave it at that and put the responsibility for "our software works" somewhere else.

It occurred to me that this has been solved in different ways in different languages. In C you tend to have pre-compile checks and compile-time checks, something we are I think kind of trying to emulate here.

But in perl, this problem has been solved in Perl by pre-installation integration tests (something problematic for us at the time). But if it were this easy, I suppose we would probably prefer this instead of blacklisting by version.

So in this particular case I am noticing: I am assuming something more central (like Math::BigFloat) we would assume could be patched in place, that we can test for misbehaviour we can reproduce, and we might not blacklist on version but all our current blacklists are in the PGObject namespace, right? If so I read the problem not as "we want to blacklist versions" but "this is a workaround because we don't have an easy way to test for these problems."

So maybe blacklisting is a workaround to that problem and something we should do sparingly. If I could suggest it would be easier to address long-term if we comment in the cpanfile when we do this why we are blacklisting a particular version so maybe later this could be moved to a test case.

...

How the user and the user's source of the package goes about fixing the bug then becomes something we don't have to know how it works or worry about.

Right. We agree there completely. But if we can't distinguish the originally broken version from the patched working version, then only packagers can solve that in the package-creation process -- which brings me to my first point: installing a mix of packages-from-dist and ledgersmb-from-source is a workaround which we should treat as such.

Right. But I wonder what the workaround is here. Blacklisting is a workaround for being unable, currently, to easily test for malfunctioning behaviour in a user-friendly way (I.e. not requiring a database connection), right?

Agreed. However, for a packager who starts from scratch, that doesn't

matter much: that packager must do all the dependencies as well as the LedgerSMB software itself. So, it doesn't reduce the work he has to do. Moreover, if things work the way they do with Debian, you have more processing time: a package needs to transition into a specific stage before you can build packages that depend on it. Which in this case means you need to build more levels of dependent packages and thus have more moments where you have to wait for the package to transition.

I don't know. The amount of work to build a first draft from a CPAN distribution at least in Gentoo is minimal. There are a lot of toolchains to get you started from CPAN to deb or rpm and while they don't get you all the way, they make a difference (and g-cpan for Gentoo takes you 99% of the way there 90% of the time). I may eventually try to get things in Portage, but gentoo overlays are actually really cool (there are even Travis-CI-based testing frameworks for *repositories*) to the point where I am not sure it is needed to get them on Portage. And there is an official status I will be pushing for which gets our repository listed in default tools (meaning installing LedgerSMB will eventually be two commands away even without being in Portage).

...

Pieces of software should have small, well defined responsibilities in my view. The thing is, indirect dependencies are not our responsibility so pushing more things to indirect dependencies makes our responsibility narrower, better defined, and ultimately easier to keep.

The idea of spinning off the templates is actually an important case in point.

While I agree with the general point of small dependency trees, I like to add a subtle addition to it:

Pieces of software should have small dependency trees *compared to the functionalities they offer*.

The reason I'm saying that is because I think LedgerSMB offers a huge deal of functionalities. By comparison, we can probably slightly reduce the dependency tree, but can't get it much smaller. The tree won't get smaller by separating out; it might not get much bigger either.

This is true. My sense though is that a narrow/deep development tree provides easier management of problems (because the tree decomposes into smaller trees nicely). In other words what you have to check at each level is a bit smaller.

As long as we have to maintain these new separated modules ourselves too (as well as our packagers), then there seems to be little benefit to dependency management as a whole. Using modules like Template Toolkit makes a great deal of sense: we outsource maintenance of the software *and* dependency tree to other developers in the community, sharing the development and test efforts. Also, Template Toolkit probably was packaged before Jame ever started his work. So, there too is a benifit. As long as we're the only user (in Debian) who use our factored out libraries, the burden will fall on Jame, though.

Yeah, which is why I would like to suggest a very slow, careful approach to this so that the burden is minimised.

...

The specific modules I would suggest we look at in the near future are the templates and the reporting engine (and actually I have immediate uses for these outside of LedgerSMB but inside the LedgerSMB ecosystem).

...

Now if we were to have the template system outside, then we have two required modules (the successors to LedgerSMB::Template, probably, the successor to LedgerSMB::Template::HTML) which are now required. Assuming that this successor has a good plugin framework and we can auto-detect any other template library we put in, we can effectively that the LedgerSMB application no longer has any responsibility to the PDF, OpenOffice, CSV, etc. generation. If someone wants to generate spreadsheets, they do:

cpan App::LedgerSMB::Template::Plugin::OpenOffice;

But we already do (for a limited set of plugins):

https://github.com/ledgersmb/LedgerSMB/blob/master/cpanfile#L61-L91

where the syntax of the command to enable PDF support is slightly different.

...

And away they go. We no longer worry about what dependencies this has.

$ cpanm --with-feature=latex-pdf --installdeps .

does exactly the same. we only specify which modules we use to make it happen. the same modules which would otherwise have been in LedgerSMB::Template::Plugin::PDF. Both would be maintained by us, right?

Right, but there's something I don't like about this. This works because we know about a module, try to load it, and see if it fails. There are two problems:

1. We get a problem report that PDF is not enabled and we don't know if it is because the module wasn't found or that it died on load somehow. This can make triaging a support issue unnecessarily problematic.

2. There is no way for someone to add their own formats without modifying the internals of our modules.

Something more like the type handler system in PGObject might be a better choice. So you load the modules and they register themselves. These can then be added to a preloads file or something.

It is not LedgerSMB's (the software) responsibility at all. The

...

template engine would have to have a plugin structure that probably couldn't change much, and an interface for interacting with plugins that could not change. But this is not actually a big difficulty in that case.

...

For pre packaged modules that's only a problem for the packager, but for git or tgz installs it's a problem for the installer. The installer of a src version then also needs to download and install many individual modules. Development installs will become harder, especially if different versions of a module are needed for different branches being worked on.

Finally, it will add additional load to our packagers. Right now Jame has quite a large number of perl packages that he deals with simply to support LedgerSMB being packaged. That can lead to delays in packaging a new LedgerSMB release if there are also changes to it's dependencies . Having even more separate dependencies will only make that worse.

I think this is actually a very valid concern. There are two very important ways we can help with that:

1. we don't release a lot of new spin-offs until the old ones are really

stable and we are guaranteeing compatibility for a while. If Debian has an old version of PGObject, as long as we support that interface... 2. we make sure we have stable interfaces before we spin things off.

I think the only way to spin off is when things are well-designed and stable indeed. Probably by having the to-be-separated-out code in exactly that state in the main code base.

I would actually suggest the only way we will know that is if we spin it off first and synchronise the changes for a while. It then is not really a bundled version and cannot be used as one. But it means we get experience testing our assumptions before we say it is ready for packagers to have to worry about because of this decision on our part.

<snip>

For that specific point, I'm against requiring that for 1.5 and lower but in master we restricted PGObject for a while with ''>=1.403002, < 2''.

Yes. We did that to suppress the warnings that the PGObject code was generating. Later it wasn't PGObject anymore generating these warnings, but PGObject-Type-DateTime was. All these warnings were fixed, so, there's no reason to keep the upperbound anymore. Each version as of 1.403.2 (=1.403002) will work (except for PGObject 2.0.0 which I remember to have a bug which broke our use)

Now do we want to keep that and make it '>=1.403002, < 2' or '>=2.000200'?

Yes.

Where will that lead us?

Currently 1.403.2 is packaged in Debian. So, that provides us Debian Jessie & Stretch backward compatibility.

How much time do we want to maintain backward compatibility for a package for which we are close to be the only user?

We may be the only *user* of the module, but not the only packager or installer. Some people (quite many, actually) rather would not use local::lib for their installations, but use the distribution's package archive.

Yves Le 2017-08-27 à 17:52:51, Erik Huelsmann a écrit :

Hi,

...

Of course we aren't there yet but I would suggest that a forward-thinking view of dependencies we might want to think about it not only regarding the dependency problems we encounter with maintaining and working on the current code but also in the question of how modularised and loosely coupled we may want the code to be in the future.

My approach here has been to put the problem of dependency declaration in a system with loosely coupled components is to be part of a design of such a module system; that is, for now, I haven't been looking too far into the future and trying to make the best out of the current situation for current package managers and installers-from-source. The immediate trigger for my previous mail was a discussion on #ledgersmb with Yves and David about the fact that Yves declared the minimum version of PGObject to be 2.0.2. I'm against requiring such a new version as the bare minimum since the code base supports anything at or newer than 1.403.2. Hence my idea about requiring a policy with a solid reasoning of why we do things the way we do. Then we also have a good foundation to evaluate the minimum PGObject version requirement.

Regards,