Two computers are working on the SAME repository but first computer detect the library and work well but second computer not detect it and show "Error 'PhpOffice\Phpspreadsheet\Reader\Xlsx' not found".
In vendor, the library also exist.
composer.json and composer.lock also the same on both computer.
One thing is that by git ignore, I use yii's composer mechanism at 1st computer but at sec computer(err computer), I add library manually.
If you want to use a composer package, you absolutely need to install it using composer. This ensures that the autoloader is generated properly and your class can be found through PHP.
Copying library files into vendor directory is not enough to install it. During installation Composer creates autoload script with information how to find all classes installed by Composer. If you just copy library files, Composer will not even know that it exist and will not able load any class from it.
If you cannot use Composer on server/computer A, you should install all dependencies on different computer (B) and copy the entire vendor directory into server/computer A. Autoload definitions are in vendor so it should work if you copy the whole dorectory.
Related
I'd like to be able to view and make changes to the source code of installed (via zef) perl6 modules. How can I do that?
On my system, the module sources are under ~/.perl6/sources/ and there's also some kind of metadata file about the modules in ~/.perl6/dist/.
I can also use zef locate ... to show a module's source path, but making changes directly to the source files doesn't seem to have any effects (i.e., use the module from the REPL doesn't show my changes).
I'm guessing it's because the modules were pre-compiled, and perl6 doesn't pick up my changes and re-precompile the modules when I make changes directly to the module source files that way...
UPDATE: Deleting the corresponding pre-compiled files under ~/.perl6/precomp/... seems to work, but I'm not sure how and if that messes up anything.
I'd like to be able to view and make changes to the source code of installed (via zef) perl6 modules. How can I do that?
Please, don't do it that way. Installed modules are supposed to be immutable and as you've found out: if there is a pre-compiled version of a module available, it will not check if the original source file has been updated. That's because it doesn't have to, because it is considered immutable.
If you want to test changes on an installed module, please download the tar file / git clone the module's distribution, make changes you need in there, and then do:
zef install . --force-install
while in the top directory in the distribution. That will re-install the module and handle pre-compilation for you.
I am installing a package manually on my own system because I need to make some changes to it that aren't available in the basic version in my package manager. I also am trying to keep packages installed locally if possible, so I'm installing it with prefix=$HOME/.local instead of the more common prefix=/usr/local.
When I do this, I have no problem executing the program from my terminal, because I added ~/.local/bin to my PATH and the package was installed with relative paths to its shared libraries (i.e. ~/.local/lib/<package>). Executing from the command line is no problem, but I want to be able to access it from the favorites menu in gnome, and for that I need to make use of the <package>.desktop file.
I could hard-code the path to the executable in the .desktop file itself, but when I pull a later version down and re-install it, I'll have to redo those steps. I was wondering if there's a way to avoid that.
I've tried symlinking the executable to a directory where .desktop files do have included in their path, and the application is correctly treated as a GUI option, but launching the executable results in an error trying to find a shared library. I think this has to do with how cmake handles rpaths, which to my understanding is a way of relatively linking executables with their required libraries.
I think what I want to do is have PATH inside a .desktop file include ~/.local/bin, without changing the .desktop file itself. Can I alter the 'default' path used in accessing a .desktop file?
The answer to my question was found in the Archwiki:
Specifically, I needed to add ~/.local/bin to my path in ~/.xinitrc. Now my graphical programs work as expected.
Some modules can be auto-updated in backoffice by clicking the update button. However if the module is from an other source than prestashop itself (e.g. github) the module needs - afaik - to be updated manually.
So how should one handle updates?
Download ZIP and
unzip it over the corresponding modules folder (/modules/acme/)
unzip and rsync it to /modules/acme (rsync -trv /tmp/acme /modules)
Same as 2 but with --delete
Delete the folder completely and unzip the new one in place like rm -rf /modules/acme and cp -a /tmp/acme /modules/acme
Others ...
Side note: what about the config.xml and possibly other generated files?
Same applies for theme updates, how to handle these?
Concerning current version Prestashop 1.7+.
If the module upgrade is made correctly (you can check if module version is updated in main module class constructor and uses upgrade scripts in upgrades folder and files inside the module) you can unzip over it. Then visit the modules list page in backend and module upgrade will run. config.xml is auto (re)generated and used only for optimizing module list loading in the same backend page - it has no effect on module behaviour itself.
For themes you can also just unzip over the last one.
When I am in doubt with any upgrades I make a development copy of the store and do upgrades there first and see if everything is ok then do upgrades on live instance.
You can perform the upgrade automatically with this free module
https://www.prestashop.com/forums/topic/820013-migrate-or-upgrade-prestashop-16-or-other-versions-to-17-%E2%80%93-free-module/
Hope it helps
How to save/restore Sublime Text 2 configs/plugins to migrate to another computer? states that, to backup a Sublime Text 2 installation, a user should preserve the ~/Packages/User directory (from the user's local data folder on whatever OS they're using).
However, http://andrew.hedges.name/blog/2012/01/19/sublime-text-2-more-sublime-with-a-drop-of-dropbox and most other walkthroughs for using Dropbox to sync Sublime's settings specify three directories: ~/Packages, ~/Installed Packages and ~/Pristine Packages.
What is the functional difference between backing up just ~/Packages/User, and the other 3 directories?
I think that Packages/User is the one in which you are supposed to put settings (according to Sublime's official and unofficial documentation). However, some people put them in the other folders from time to time.
The Dropbox advice may be a hedge against poor practice.
From here:
Installed Packages is:
You will find this directory in the data directory. It contains a copy
of every sublime-package installed. Used to restore Packages.
These are the packages installed as sublime-packages. I don't think package control uses this, but if you install something as a sublime-package maybe you want to keep it?
Pristine Packages is:
You will find this directoy in the data directory. It contains a copy
of every shipped and core package. Used to restore Packages.
So essentially a list of .sublime-package files used to restore if you break something.
Packages is:
The packages used by Sublime Text, either installed as part of sublime, or the plugins.
User is:
The user directory is your personal directory, containing configurations, additional snippets, etc.
Below are my personal views on what to save, so feel free to ignore it if you would like.
I would have to agree with the post saying just save the User directory, as Package Control will grab all of the plugins in the list if they aren't already installed. I didn't see this mentioned in that post, but you can also add repositories (by specifying a URL) to Package Control, which allows you to install Packages outside of those submitted to Package Control, but still hosted somewhere. One of the arguments I can see to saving the Packages directory completely is if you are using plugins that aren't hosted anywhere (though these could probably be moved to the Packages directory without any problems).
The Installed Packages and Pristine Packages are used to restore packages, so I wouldn't think these would be needed, but I'm sure there is some use case where it is.
Anyways, realize I got off topic a bit at the end there, but hope everything before that helps clarify.
I use the deb file for production and the source for development.Is this the correct way to do things?
I think that the deb might have certain optimizations(pyo or pyc) for production environment.
But since I have to move my custom modules, one at a time to the production,I find it increasingly difficult.
The actual addons path is here
(1) /usr/share/pyshared/openerp/addons
But the init.d points to
(2) /usr/lib/pymodules/python2.7/openerp/addons
In some modules the __init__.py is in 1 (eg: web_rpc)
and for some its in 2 (eg: hr)
What the actual difference btw
http://nightly.openerp.com/6.1/nightly/src/
and
http://nightly.openerp.com/6.1/nightly/deb/
I haven't tried the deb files, because we use the Ubuntu all-in-one script from openerpappliance.com. It downloads the source from Launchpad and then runs the deployment scripts for you. It will also do updates after you've installed.
We're very happy with the 5.0 version, but we haven't tried the 6.1 version, yet.
you can do with 6.1 is you can give multiple addons path to the your config file in comma separated , or else you can create link in addons folder for your customized folder while you can keep cumized module where you want, just put link(shortcut) to the addon sfoderl of your. this will give you flexibility.
Thank YOu