I setup a class in my site.pp
class packages {
Package { ensure => 'installed' }
package { 'python-devel': }
package { 'blas-devel': }
package { 'lapack-devel': }
}
but nothing seems to be happening?
when i run
pip install scipy
I still get that Python.h cannot be compiled so I take it python devel didn't install
You have defined class 'packages', but you do not show that class being assigned to any node. That's like writing a function but never calling it.
You need to declare that class to assign it to specific nodes or to all nodes (depending on the context of the declaration). There are a few different forms for that, but about the simplest thing you could do would be to add ...
include 'packages'
... on the line after the closing brace of your class definition.
The result will still be in rather poor form, as classes should be defined in modules, not in site.pp, and declarations rarely should appear at top scope (outside any node block, class definition, or type definition), but it will instruct Puppet that when it runs, it should ensure that the packages you specify are installed.
Actually, the way you wrote the code for the modules doesn't look right. I would try something more like the following
class 'my-python' {
package {'python-devel':
ensure => installed,
}
package {'lapack-devel':
ensure => installed,
}
package {'python-devel':
ensure => installed,
}
}
you define each of the packages within the class as seperate package resources. Then you need to 'include mypython' in your site.pp for the node you want to install them on. Run puppet and you should be good.
Related
This question is a follow-up to:
Running Vuetify on Vert.x (w/ES4X)
I would like to be able to run ES4X via Eclipse (instead of NPM). I'm not exactly sure if it's possible or how to wire it in.
Let's say I have the following build.gradle.file
plugins {
id 'java'
id 'application'
id 'com.johnrengleman.shadow' version "5.0.0"
}
sourceCompatibility='1.8'
mainClassName='io.vertx.core.Launcher'
repositories {
mavenCentral()
}
dependencies {
implementation 'io.vertx:vertx-core:3.7.1'
implementation 'io.vertx:vertx-web:3.7.1'
implementation 'io.vertx:vertx-lang-js:3.7.1'
// implementation 'io.reactiverse:es4x:0.8.0'
// implementation 'io.reactiverse:es4x-pm:0.8.0'
}
processResources {
from '/src/main/js'
}
shadowJar {
classifier = 'fat'
manifest {
attributes 'Main-Verticle' : 'index.js'
}
mergeServiceFiles {
include 'META-INF/services/io.vertx.core.spi.VerticleFactory'
}
}
and my src/main/js/index.js looks like the one from the other referenced post:
import { Router, StaticHandler } from '#vertx/web';
const app = Router.router(vertx);
app.get().handler(StaticHandler.create("dist"));
vertx.createHttpServer().requestHandler(app).listen(8080);
If I create an executable jar via shadowJar, I get javax.script.ScriptExceptions due to Nashorn choking on the index.js contents (as expected).
If I uncomment the es4x implementation in the gradle build, I get ClassNotFound exceptions for org.graalvm.polyglot.io.FileSystem
So how would I correctly modify this app to take advantage of ES4X? I guess the equivalent of what the 'es4x init' would do?
Say that you have your es4x application and a package.json, when you execute:
npm install
You will get inside node_modules a few extra folders:
.bin
.lib
In the .bin directory there is a es4x-launcher.jar file you can use to start your application from Eclipse. It will refer to the dependencies which are unpacked to the .lib dir. In order to make things work fine the same JVM you have when running the npm install command should be used in eclipse. Otherwise you might end up missing dependencies. This is the case when running graalvm which will not require graaljs dependencies or when running on jdk8 which will not require jvmci dependencies.
I'm little confused by various terminologies used in the SystemJS configuration. It talks about module, location, package etc...
Isn't module in JS is a single file, and package is a collection of modules or files? If so, how a module can be an alias to a package?
This is from the documentation page:
The map option is similar to paths, but acts very early in the normalization process. It allows you to map a module alias to a location or package:
Yes module is a single file, in javascript it's just the file name (with assumed .js extension) in quotes after from keyword in
import ... from 'some-module';
In SystemJS config file, paths and map can be used to define what actual file or URL that some-module refers to.
packages in config file allow you to apply a set of configuration parameters (default extension, module format, custom loader etc) for all modules in or below particular location (the key in packages object).
One of the settings in packages is main, which is similar to main in package.json in node (except that it's default value is empty, not index.js): it determines which file is loaded when the package location itself appears in from in import statement.
So, I think "how a module can be an alias to a package?" question about this
The map option is similar to paths, but acts very early in the
normalization process. It allows you to map a module alias to a
location or package:
can be explained on this example:
paths: {
'npm:': 'node_modules/'
},
map: {
'some-module': 'npm:some-module'
},
packages: {
'some-module': {
main: './index.js'
}
}
when these map, packages and path settings are applied by SystemJS to
import something from 'some-module';
they will cause SystemJS to load a module from node_modules/some-module/index.js under baseURL.
and
import something from 'some-module/subcomponent';
is mapped to node_modules/some-module/subcomponent.js.
Note: this is based on my experience with SystemJS 0.19. I haven't tried 0.20 yet.
I'm using Puppet to install a specific kernel on an agent. The problem is, I can't quite seem to give it a version. I have the following:
class kernel::install_kernel_version {
# Make sure the 'kernel' package is installed in build agent
case $::osfamily {
'RedHat': {
require epel
package {'kernel':
ensure => '2.6.32-431.29.2.e16.x86_64'}
}
default: {
fail("Module is not compatible with ${::operatingsystem}")
}
}
}
Every time I to run it, there's no effect. Presumably because it doesn't know the kernel version exists.
I get the following warning whenever I start my Scala application:
WARN - imported `SVNProperties' is permanently hidden by definition of object SVNProperties in package core, at line 4 of app/core/SVNResource.scala
What could this mean?
You probably have code that looks something like this:
object Hidden {
import scala.collection.immutable
object immutable { def x = 7 }
}
except in a less obvious way. You're importing something--in my example, the package immutable--and then you go and define something else with the same name that prevents you from using what you imported.
In particular, it looks like you tried to import SVNProperties into SVNResource.scala, except that SVNResource.scala defines its own SVNProperties which hides the import.
I encountered this warning after moving some classes from one package to another. I guess there was some conflict between the new location and binaries from the old location. In my case this helped:
sbt clean
I got this warning when my class was importing classes in the same package.
Once I removed the unnecessary import, the warnings were removed.
This happened to me after moving a class from one package to another, like in astasiak's case. I ran sbt clean with no luck. For the life of me, I couldn't find the class in the old location.
However, I had other errors preventing me from building. When I fixed those, this error disappeared. My guess is that until you can build cleanly, sbt still thinks you have the class is in the old package, and includes this error with any other build errors that are preventing you from building.
My advice? Check for other compilation errors and fix those -- you might be erroneously getting this error due to sbt having an outdated view of your package structure since its last successful build.
Just to further expand on a comment posted by Nick, as this was the case for me:
Another common cause is that SVNProperties is in the same package and so is already in scope. Trying to import it explicitly results in this warning.
More concretely, you may have:
package app.core
// No need to import the following - it is already visible as
// you are in the same package
import app.core.SVNProperties
object SVNResource {
Use instead:
package app.core
object SVNResource {
(Opinion) As a matter of coding style you may want to camel case your variables differently like for eg. SvnProperties, SvnResource. It reads easier for most people, see also this question.
I had a main class with name Server and I was creating a jetty server in the main class in the following way.
import org.eclipse.jetty.server.Server
var server:Server=new Server()
I got the below warn on running sbt run
> [warn] /home/xxx/xxx/xxx/src/main/scala/com/xxx/xxx/main/Server.scala:3:
> imported `Server' is permanently hidden by definition of object Server in package main
[warn] import org.eclipse.jetty.server.Server
[warn] ^
[warn] one warning found
I renamed my main class and the warning disappeared.
If you are using Scala Eclipse IDE you can do :
Project > Clean...
After that all the warning will be removed.
Also, make sure the name of the package you import =/= object name.
I got this by having circular dependencies. Both my classes were using each other on accident.
If the warning comes from importing a class with the same name, you can always use import renaming.
package domain
case class Company (...
package models
import domain.{Company => _Company}
object Company extends SkinnyCRUDMapper[_Company] {
Issue is related to dependency conflict, When you have same class in multiple Jars compiler found one of class is hidden and gives an error.
check for your Jar version is same across project or try to change name/package for one of conflicted class
I have inherited a web project that is perl based and I'm attempting to set up a local testing server so changes can be made internally to the project.
The server architecture
Ubuntu 9.10
php 5.2.10
mysql 5.1.37
perl 5.10.0-24ubuntu4
All the dependent modules and packages are installed such as DateTime.pm, TemplateToolkit.pm but running the application throws the following error message:
Can't locate object method "new" via package "Template" (perhaps you forgot to load "Template"?) at ../lib//KPS/TemplateToolkit.pm line 51
The code block that this refers to is:
sub new {
return Template->new(
INCLUDE_PATH => $KPS::Config::templatepath,
ABSOLUTE => 1,
DEBUG => 1,
);
}
If anybody is able to shed any light on this or point me in the right direction it would be greatly appreciated.
Thanks
Simnom
You need to load Template Toolkit first, with:
use Template;
To make sure that Template::Toolkit is properly installed on this system, from a console you could run:
perl -MTemplate -e0
If it returns without an error, it means Template.pm wsa loaded succesfully; if not, it will give you an error of "Can't locate Template.pm in #INC...".
An additional thing to check because the accepted answer test could be successful even if you are not setup correctly; make sure that the package declaration in the module has the correct path. The scenario is as follows:
You do
use a::b;
...
a::b->new();
and then in b.pm you do
package b;
You may be banging your head for a while until you realize that you need to do
package a::b;