I have a package I want to install. I would like the files to end up in a different directory than the installation wizard choses for them.
For example, my Sitecore copy is running at C:\SiteCore\website
The module added files to C:\SiteCore\website\Console
I would like the files to ultimately live at C:\SiteCore\website\sitecore_modules\Console
I am using Sitecore 6.5 rev 111230, but we are planning to upgrade very soon. I would like for my installed packages to migrate seamlessly once we have upgraded. For reference, the package I want to install at the moment is the Sitecore Powershell Extensions. Although, I would prefer to apply a similar method to any future packages that I install.
Is there a secret switch in the package installation process to allow me to do this? Can I do it from the package installation wizard? Is there another way to install packages?
I'm assuming I can't just change the package path and expect everything to keep working. Do I have to update a configuration somewhere (a file or inside the Sitecore CMS GUI) to make the package recognize the new file locations?
The module creator defines where files exist. If you move them you run the risk of something not working. The best idea is to ask the creator on the Marketplace page of the module.
There is no turn-key way to change this.
I guess you cand take the code from MarketPlace and you can modify it.
I don't know how exactly is the licenses with MarketPlace modules, but I think people can modify others code.
Please check on code and also on items, maybe on some fields are values for folder path.
I discovered a way to accomplish this, but it can be quite involved or even impossible, depending on the complexity and size of the package.
First of all, I did take the question to the module creator and had a very helpful and informative conversation with the creator. So thanks for that suggestion - they may even move the install location in a future release, based on my request.
The workaround is to first install the package on a system as normal. Then you figure out everything that comes with the package. For files, this is easy if your Sitecore root is under source control. For items, this is really complicated. You can search for the installed items by owner, if you had the foresight to create & use a unique user for the package installation. Or you can check the untyped files in the package that are essentially xml based item manifests.
Once you have a detailed list, you make the desired modifications to the locations. Then you recreate the package yourself using the Sitecore package designer.
This works for simple packages - I did it to one small package that I hope to get up on the Sitecore marketplace as shared source soon. And by small, I mean it was 2 files and 3 items. The package that prompted me to ask this question would not cooperate with this workaround. The included .dll had some assumptions about the file structure hard-coded into it.
The workaround I took for the more complex package was really quite basic: I just created a new source-code external to the required path. That let me wrap everything up neatly without getting medieval on the package files.
Thanks for both your answers, a very fine +1 to you.
Related
I'm new to ember and after following a few guides, I've been playing around with ember apps. I'm using ember-cli to create an app, so I use
$ ember new 'app-name'
which creates the app as expected with the 'app' and 'dist' folder. But it also creates a lot of other files. I only discovered this while deleting the folder when the windows delete dialog box showed deleting more than 30000 files.
Is it that I'm doing something wrong that's causing unnecessary files to be created? Is there a way to avoid this?
You aren't doing anything wrong, a big portion of it is the dependencies and then the build process keeps a lot of temporary files around for reuse.
By the way, if you are developing in Windows, make sure you are running your command prompt as administrator, and that you've excluded the ember app from the virus scan, it really improves the build times.
It's not an issue with ember-cli itself, but how npm handles dependencies, since it has a hierarchical dependency system. You could try npm 3 (be warned, it's still beta - changelog), which tries to flatten out the dependencies better.
Another thing is checking if bower packages are adding any unneeded dependencies, like tests or raw source files (if they have pre built files). You could submit a PR to those projects by adding the ignore property in the bower.json file. See the spec here. Same with npm packages, which has a .npmignore file.
This is probably not what you wanted to hear, but in open source, we must all help each other. These are the bread crumbs of open source, and a great place to get started.
What is the best way to uninstall a package or a module in Sitecore?
I've seen suggestions to do it manually, but it is not very convenient way, especially when there were many templates, items, layouts, renderings and static files.
You can use Sitecore Rocks to create an "anti-package."
https://www.sitecore.net/nl-be/learn/blogs/technical-blogs/trevor-campbell/posts/2013/02/28-days-of-sitecore-rocks-package-management-part-1.aspx
I have never tested the Package History module that was mentioned, so I cannot comment as to whether that approach works.
Open the .zip file for the original package and look through the XML to figure out what files the package installed. Then back up your site and remove files and configuration nodes the package installed(assuming you are confident you understand what purpose the files and nodes have and what other components may rely on them). The Package History module may be taking this same approach, but you need to be certain that what you are deleting is not going to break anything.
Otherwise, I would recommend restoring to a backup made before you installed the package.
All over the web, the answer to the question "uuid.h not found" is "install some kind of rpm or deb file". This may be appropriate for attempting to build some kind of open source project, which has dependencies on other open source, but it does not seem correct for building one's own software.
At my company, most of our own code can be built by getting the code from our source control and building it. Dependent headers, libs, etc. are included in the sync. However, whenever someone gets a uuid.h not found, soemone always says "do apt-get install uuid-dev" or something like that.
My question: what is so different about uuid.h that it must be installed like this? Our code uses ODBC too, but we don't need to "install" odbc headers. Ditto xml parsers, and many other third party code.
I don't think there's anything magical about uuid.h that requires a packages installation; just that installing the package is a simpler step than adding the required files one by one, and it will be easier for you to keep them up to date through your Linux distro's package update utilities.
So installing the package is the simplest way to get a user going, and will keep them up to date without manual intervention. I suspect there is a way to build from source and add the files one-by-one, but that is not as simple.
I have found a problem with the test environment in a c++ problem.
We have a machine which downloads the code from the version control system and, build it and execute the unit test, nothing new.
The problem arise when we add a new dependency in our project. We are developing a lot of features at the same time and it is something relatively common. We this happens we have to advise testers and give them an easy way to reproduce the compilation environment ...
And I was thinking if there is any other easy way to go through this ... don't know, some tool like virtualenv or buildout for python ..
I have been searching at google, but with no luck.
Any help will be appreciated.
You can always add all of the dependencies to the revision control system and provide automated scripts that will install the required subsystems. Where I work, if you just download the current version from the repository, you can build in one step an ISO image that can be installed by testers in any computer they want. The image contains everything from the OS up to the application.
Depending on your particular situation, you might want to start with smaller steps, like adding the dependencies to the repository and having the testers check there whether any new file appears or changes version.
No ready tool, AFAIK, except maybe for CMake which can control things like that for you.
For C++, it's fairly easy to manage "by hand" since you can set LIB, LIBPATH and PATH environment variables to carefully selected directories. No site.py, eggs, .pth files and the like as with Python.
We do this at our shop, setting up our build/development environment closely and have everything in revision control (mostly scripts that download huge zips of prebuilt libs and unpack them to the right places).
Small libs are copied to common dirs, larger get their own entry in the env-vars.
This works equally well for Python and Java. Haven't tried other languages...yet. :)
I am working on an ecommerce site, based on django-lfs, and I am finding that I need to make a number of changes to the django-lfs core files... i.e. adding additional properties to models, updating views, adding url patterns etc. I started out placing django-lfs in my pythons site-packages path with the view that if i needed to make any changes to the code I would either re-define the url pattern (in the case where i needed to do something different in a view) or monkey patch code.
The thinking behind this was that i'd be able to keep the original django-lfs trunk clean and un-touched, allowing me to update it to the most recent version and then independently update / test the local overrides, subclassing and monkey patches written.
As you might have guessed, this is quickly becoming a bit of a nightmare to manage so i'm in desperate need of a cleaner and more stable solution.
The client project sits in a git repo and so i have been looking into submodules or subtree merging strategies... from everything i have read though, I am finding it difficult to find any definitive answers that are simple to understand (i'm relatively new to git).
In short, I need to be able to:
1) Include an external git repository into the main projects repo
2) Either make changes directly to the external repo (but have it push to the projects git repo and not to the external remote origin) OR create a local copy of the external repo and then periodically merge the external repo with the copied folder.
I have no idea how to achieve this though. to be clear, I would like to end up with the following folder structure:
PROJECT_NAME
MEDIA
TRUNK
APPS
django-lfs
EXTERNAL-REPOS
django-lfs
The lfs app in the external-repos folder should be able to pull down updates from the official (external) django-lfs repository and i should be able to freely make changes to tehe lfs folder stored in the APPS folder.
What i'm looking for, if at all possible, is a set of git commands / instructions to achieve the above and that make use of the real-worls folders outlined above, rather than using foo and bar references.
I hold my fingers tightly crossed and hope that someone out there can offer some advice :)
My quick take on this: either fork the project on bitbucket or github (depending on your preference of hg vs. git) and make a branch for your changes.
This will make it easier to keep your branch and the official master in sync.
Then, assuming you use pip+virtualenv, add the pointer to your repo/branch in your pip requirements file.
Unfortunately LFS uses buildout, so not quite sure what the equivalent of python setup.py develop would be (i.e. to install the package in your virtualenv site-packages but with links back to your repo so you can make changes without having to constantly run setup.py).