Comments (15)
YAML::XS
is provides by perl-YAML-LibYAML
but it seems the rpm deps are completely missing. i'll make sure this gets fixed.
there will be more dependencies that are now required to complete the tests.
from caf.
It was my guess but the version in EPEL SL6 doesn't seem to provide YAML::XS? Have you checked?
from caf.
http://dl.fedoraproject.org/pub/epel/6/x86_64/perl-YAML-LibYAML-0.38-4.el6.x86_64.rpm seems to have it
from caf.
as a general question: do we want explicit dependecies on the possibilities of TextRender?
currently support for e.g. tiny
is sort-of dynamic, in that CAF::TextRender
will try to load the dependency module (check for $self->load_module('Config::Tiny')
.
but we could make it mandatory so one is sure that tiny
will work (e.g. with a general use Config::Tiny
, nothing dynamic at all). this will then trigger the dependency in the rpm (i have no clue wrt solaris @ned21 does the solaris packaging translates a use X
statement in a perl(X)
dep like rpmbuild does?).
adding the depency in the pom.xml fixes the dependency on some perl modules, but then we might as well switch to the use X
instead of the dynamic load_module(X)
.
from caf.
Clearly, you are right: this is not very good to define a static dependency if the dependency is in fact optional, based on the actual configuration...
from caf.
We have always enforced these dependencies in the metaconfig RPM. The reason was that most profiles will require multiple modules (f.i, Template::Toolkit, Config::Tiny and YAML::XS), and discovering that a valid profile fails when executing the component is fustrating, and difficult to troubleshoot.
from caf.
@Piojo so we require the dependecies and get rid of the load_module
? or we leave the depencies in e.g. metaconfig pom.xml
? (and any other piece of software that needs specific modules, has to add the deps themself?). i'm in favour of the second (it's clean, CAF dependencies stay minimal), although developers should be aware of this.
but i'm against this behaviour for the tests. the tests should test all functionality, so no missing modules are allowed for that imho.
from caf.
Dependencies and tests are in fact 2 different things as you generally don't install the RPM to test things... But probably we should pay attention to have explicit error messages about missing modules when failing tests (I think it was basically the case in this case, not sure in other components). I tried to had any test dependency I discover in rpms/quattor-development.pan
in the OS templates.
I tend to share the opinion of @Piojo that we should avoid to have a valid profile leading to an error because of a missing dependency. So probably we should ensure that required RPMs for supported CAF::TextRender
format are listed as a dependency (despite it will had quite a few RPMS not necessarily needed, not a problem as long as they are in the OS or EPEL) and a clear message if it happens that something is used and that there is a missing RPM.
from caf.
so what is the conclusion: we move the dependencies here via the pom.xml, but leave the code with the dynamic load_module
? (eg on solaris, the pom dependencies have no effect since they are rpm specific).
from caf.
If there is a potential for the code to be called, then these should be explicit dependencies.
from caf.
I am a little bit conflicted on this one. I agree that a valid profile should ideally never "fail" due to a missing RPM, but at the same time, additional RPM requirements can be a real pain to support across multiple OSes--how long do we plan to support SL5 for? At MS we will have to support RH5 for several more years.
In this case I think the extra formats are sufficiently useful, and the number of rpms sufficiently small, that it's worth making them part of the dependencies.
from caf.
@ned21 : we have not discussed EL5 support timeline but I can't imagine we drop the support before it is end of life, i.e. end of 2017 if I'm right... So certainly a good number of years...
from caf.
When I wrote load_module
, I thought metaconfig would be used for just a small amount of files, and hence it didn't make sense to bloat the system or the runtime with more modules, "just in case".
This seems to have changed now: most profiles use most modules, sometimes a lot. In that case, declaring statically the dependencies (with use
statements) looks like the most maintainable solution in the long term.
from caf.
i propose then to do the following:
- for the current supported formats we add the dependencies via
use
- we keep the
load_module
code in case people want to add more external modules that generate formats, without having to increase the bloat ofCAF
(or e.g. in case we don't agree it's good to add it because it breaks support for some OS). but in that case it will be up to the developers who use this functionality to make sure the dependencies are satisfied.
from caf.
i modified #67, please review
from caf.
Related Issues (20)
- CAF::Reporter struct logging fails on el5 due to missing strict TT mode HOT 2
- CAF::Path documentation: methods should be in alphabetical order or grouped in sections
- CAF::FileWriter Can't call method "can" on unblessed reference at line 353
- filewriter_notmocked.t fails on SL6 HOT 1
- Unittests on el5 fail due to perl warnings HOT 1
- FileWriter: confusing same message with `cancel` and `close` with save=0
- CAF::FileEditor from source broken HOT 3
- CAF::FileWriter: reported diff does not end up in verbose logfile HOT 1
- CAF::FileWriter default permissions HOT 5
- CAF/LC default permissions HOT 1
- CAF::Process output that ends up on stdout is not part of logfile with verbose_logfile
- CAF::Service: Providing restart-if-running (conditional restart) functionality. HOT 4
- CAF::Process: Include an option to execute the command as an specific user HOT 1
- CAF::Process: Include sensitive option HOT 5
- CAF::Process supports shell option HOT 9
- Filewriter: modify permissions when content is unmodified HOT 3
- Problems with #258 HOT 2
- CAF::FileWriter TODO from pod - drop LC::*
- CAF::FileWriter should use external diff command for large files
- CAF::Process allow environment to be specified
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from caf.