I want to make use of "TimeStampAwareModel" but I don't know what will be its package that I can import?
Please suggest me the package to use it?
There doesn't seem to be a reusable package that provides TimeStampAwareModel.
Searching GitHub brings up a few repositories that contain it, for example django-newsfeed.
It would probably be easier to define TimeStampAwareModel in your own models.py, rather than installing one of the repositories.
Related
In an Ember CLI app. If one wanted to use https://github.com/twbs/bootstrap/blob/master/js/tooltip.js
http://www.ember-cli.com/ does not seem to mention anything specific about this.
Where would this file typically be stored? At first glance, I was thinking of putting it in public/assets/js. What is the convention, if any?
Yes there is a convention. Use bower if a package exists. If it doesn't, download the repo into the vendor folder. Import the file in your Brocfile.js
app.import('vendor/path_to/main_js_file.js');
Yes, use bower or place them in vendor/. Then register them in ember-cli-build.js
Here's the documentation: https://guides.emberjs.com/v2.14.0/addons-and-dependencies/managing-dependencies/
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.
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.
I'm integrating two Django apps together, but am finding that one requires django-mptt version 3.x and the other requires 5.x. I can't upgrade the 3.x app because I don't 'own' that particular app and it might be needed for some old dependencies.
Is there any way short of forking and namespacing the django-mptt 5.x version so both can be used? I'd really hate to fork it and am wondering if there are better options out there.
Just wondering what others have done in similar situations. Thank you for reading.
This is not possible with the usual python tools, since virtualenv are supposed to be used for that.
One possibility is to put each version of the dependancy in each app directory, this way they may import this one first instead of the other.
But if your goal is to not edit any of the apps code, you better prey they don't play with the Python Path, nor share any imports related to the dependancies.
Moving my project from Ant to Leiningen went so smoothly that I am looking at new things to include in the build process. one of which would be to automatically create a .deb and .rpm file in the build. What is the easiest way to do this?
I think your best bet would be to write your own Leiningen plugin for this (which I hear is pretty easy), or use the lein-scripts plugin and write a script/task for it.
It would be really great to have a lein plugin to help with this. Since it already uses maven under the hood, you could look into using the maven-unix-plugin (http://mojo.codehaus.org/unix/) which can build .deb and .rpm files. Otherwise if that looks annoying I don't think either package format is especially complex. You could probably do it by hand in Clojure, in which case maybe looking at some example Ruby Rake tasks would help. (http://rubyforge.org/projects/pallet/)
I've come across the same problem. I followed rosejn's suggestion and created a Leiningen plugin that uses the RPM Maven Plugin to create an RPM. I've put it here.