My collegue and I develop a small Python application. We use Vagrant to set up development environments.
Suppose my collegue introduces a new feature into the application. Feature's implementation requires a new python dependency (3rd party package) and the dependency itself needs some system libraries. If I do not read through all pulled commits carefully I can miss, that some systems libraries have to be installed prior running the project.
Of course we update Vagrantfile to install such non-python dependencies during provisioning, so if someone clones project's repository and issues vagrant up he will get a fully working development environment, but what shoud I do to automate updates in my existing environment?
How should we indicate, that a new dependency (python or non-python) was added and we need to install it by firing a specific command?
UPD I can try and run the application and if I encounter any errors it is a sign to reprovision my vagrant box, but it seems tedious to me to test a feature by hands and run provisioning scripts later
I ran into this with Ruby as well. We used Bundler, which is a dependency management system for Ruby. If I pulled in new code, ran it and got funky exceptions saying that a certain dependency was missing, I just knew it was time for a bundle install from the command line. The solution to your problem is the same. If you run the code and get errors saying a dependency is missing, your default response to that exception should be to vagrant up on the command line, and try again.
Barring that, sending an email to your teammates with instructions about the new or updated dependency is a good way to go, especially if a vagrant up is insufficient to resolve the missing or incorrect dependency.
Related
My company is using an old CentOS6 and they wont update it before months (years?). This is totally out of my control and it obviously makes using up to date software a nightmare.
I would like to use Visual Studio Code as a C++ IDE but its intellisense plugin is running with glibc >=2.14 and Centos6 comes with glibc 2.12.
It also needed some more dependencies I managed to recompile and load with LD_LIBRARY_PATH. I tried compiling a new glibc and load it as well but it segfault, as expected.
I used the compiled version of VSCode from the official website.
I tried compiling it myself but it requires to download many files and my virtual machine does not have Internet, I can only transfer files through ftp. I created a local yarn repository, compiled all appropriate version of Yarn, NodeJS but a compiled binary is trying to download electron and I have no idea where to put the file to trick him into thinking it's downloaded already (assuming I could).
There are standalone solutions to run software on old distribution, like AppImage but VSCode is not part of their apps.
Would you have any idea on how to run VSCode on Centos6? Did you ever try to compile VSCode without and Internet Connection?
Currently the only viable solution I see would be to create an AppImage at home.
To run VS Code Server on CentOS 6, I followed the "glibc and libstdc ++ on RHEL / CentOS 6 update" article from here.
Perhaps this option will help you.
I am using ActiveReports6 for my windows forms application
When I install it on my machine providing serial key it works perfectly fine.
But when I don't install it, it shows this red line in the bottom of the report
The document was created using an evaluation version of activereports..
My understanding may not be correct, but what I tried is I installed licensed version of ActiveReports6 to my computer and then copied all the dlls generated for ActiveReports6 from GAC and added them to my project thinking now they will work on any machine as they are generated by licensed version of the software.
And then uninstalled Activereports6, but when I tried it still gave me the same evaluation version message.
So is it mandatory that active reports has to be installed in all the machines where I deploy my client? Or I did something wrong
The license for development. You would install activereports, create your reports and build your application on the licensed machine, the VS compiler will automatically check the licensed components and include the license within your application. You do not need to install ActiveReports itself on your client, only make sure that you are deploying the ActiveReports assemblies with your application. if you are having any issues please contact us at http://activereports.grapecity.com and we would gladly resolve the issue for you.
Found the mistake I was doing.
Actually I had put licenses.licx file in the subdirectory of the project while it should be in the same directory of the project and so I was not generating its exe.licenses file and so did not work.
Once I changed the location of licx file it worked!
Thanks!
I'm using the Marmalade System Deployment Tool to (Package and Install) an App to my playbook. It's packaging properly but when it gets the deployment I get this error, (ERROR: error running blackberry-deploy) and this is the log error.
SUCCESS: EVALUATION USE ONLY package written to 'c:\Users\George\Documents\Marmalade\build_helloworld_vc10\deployments\default\playbook\release' [took 3.05s]. This package is not licensed for commercial use
--> deploying to device from: deployments\default\playbook\release
[execute] blackberry-deploy.bat
ERROR: error running blackberry-deploy
ERROR
Would anyone know how to fix this problem?
You don't have the standard License from marmalade. You need to buy either standard, indigo or basic license (I hope the names are correct).
You are currently using their 90 days free evaluation license, which does not support deploying on devices (Why should they support, if it's for free).
Try to compile a package but don't install, use this program for install applications, easy as piece of cake.
http://hatax.home.comcast.net/~hatax/bb/Playbook_Tools.zip
It's not the same download as mine 'cause I cant post numeric domains(IP) in this forums.
I almost turned crazy tryng to solving this. I hope it can solve your issue too.
Javi.
What are the best practices for deploying a Perl application? Assume that you are deploying onto a vanilla box with little CPAN module installation. What are the ideal build, deploy methods? Module::Build, ExtUtils::MakeMaker, other? I am looking for some best practice ideas from those who have done this repeatedly for large scale applications.
The application is deploying onto a server. It's not CPAN or a script. It's actually a PSGI web application. That is, a ton of Perl packages.
I currently have a deployment script that uses Net::SSH::Expect to SSH into new servers, install some tools and configure the server, then pull down the desired application branch from source control. This feels right, but is this best practice?
The next step is building the application. What are the best practices for tracking and managing dependencies, installing those dependencies from CPAN, and ensuring the application is ready to run?
Thanks
The company that I work at currently build RPMs for each and every CPAN & Internal dependency of an application (quite a lot of packages!) that install into the system site_perl directory. This has a number of problems:
It is time consuming to keep building RPMs as versions get bumped across the CPAN.
Tying yourself to the system perl means that you are at the mercy of your distribution to make or break your perl ( in Centos 5 we have a max perl version of 5.8.8 ! ).
If you have multiple applications deployed to the same host, having a single perl library for all applications means that upgrading dependencies can be dangerous without retesting every application of the host. We deploy quite a lot of separate distributions all with varying degrees of maintenance attention, so this is a big deal for us.
We are moving away from building RPMs for every dependency and instead planning to use carton [1] to build a completely self contained perl library for every application we deploy. We're building these libraries into system packages, but you could just as easily tarball them up and manually copy them places if you don't want to deal with a package manager.
The problem with carton is that you'll need to setup an internal CPAN mirror that you can install your internal dependencies to if your application depends on modules that aren't on the CPAN. If you don't want to deal with that, you could always just manually install libs you need into local::lib [2] or perlbrew [3] and package the resulting libraries up for deployment to your production boxes.
With all of the prescribed solutions, be very careful of XS perl libs. You'll need to build your cartons/local:libs/perlbrews on the same architecture as the host you're deploying to and make sure your productions boxes have the same binary dependencies as what you used to build.
To answer the update to your question about whether it is best practice to source checkout and install onto you production host; I personally don't think that it is a good idea. The reasons why I believe that it is risky lays in the fact that it is hard to be completely sure that the set of libraries that you install exactly lines up to the libraries that you tested against, so deployments have the potential to be unpredictable. This issue can be exasperated by webapps as you are very likely to have the same code deployed to multiple production boxes that can get out of synch, also. While the perl community does a wonderful job of trying to release good quality code that is backwards compatible, when things go wrong it is normally quite an effort to figure things out. This is why carton is being developed, as this creates a cache of all the distribution tarballs that you need to install frozen at specific versions so that you can predictably deploy your code. All of that said though; if you are happy to accept that risk and fix things when they break then locally installing should be fine for you. However, at the very minimum I would strongly suggest installing to a local::lib so that you can back up the old local lib before installing updates so you have a rollback point if things get messed up.
Carton
local::lib
perlbrew
If it has some significant CPAN dependencies, then you might want to either write a small script that uses CPAN::Shell to install the necessary modules or edit the Makefile.PL of your application so that it reflects the necessary dependencies in the BUILD_REQUIRES portion of the file.
You may take a look at sparrowdo a perl6 configuration management tool, it comes with some handy plugins related to perl5 deployment, like installing cpan packages or deploying psgi application.
Update: this link https://dev.to/melezhik/deploying-perl5-application-by-sparrowdo-9mb could be useful.
Disclosure - I am the tool author.
virtual machines hold great promise as a way to distribute hard to configure applications. i have been using jeos vmbuilder (and some bash scripts) to generate my appliances, but i'm looking for something more elegant.
in my case, i'm looking for a solution that will build a linux-based vm with configured versions of tomcat and mysql as a base. each future release would be a new war file and a sql update script. it'd be really nice if already deployed vms could self-update and test builds could be pushed to ec2.
in my brief search, i've found rpath rbuilder, turnkey linux,
vagrant up, suse studio, jeos vmbuilder, and vmware studio. rather than try all of these, i figure i'd ask what this community uses to build and distribute appliances...
I use pungi myself.