I've not used Conan before. I've now installed it, and I basically know how to install a package with it, but - I need to find packages.
I've gone here: https://bintray.com/conan/conan-center
and there's a search interface, but it seems to ignore package descriptions and only try to match package names. This is really problematic, for obvious reasons.
My question: Other than scrolling through packages, what can I do to search for packages by matching description text?
There is a new interface, including a new search service, in https://conan.io/center/. The search might be a bit better, but not yet indexing the full description fields.
The packages are now generated from pull requests submitted to the conan-center-index repo, and issues specific to the Web UI, including the search functionality can use the "conan.io/center" label. Some of the current suggestions include navigating by topics. Indexing the descriptions will be done, hopefully soon.
In the meantime, cloning and grepping the conan-center-index repo is a very convenient/pragmatic way to find things including descriptions
Related
So how does the "replace" property work with composer? I have read the composer document but still not understand it. Searching for more info hasn't answered my questions.
When I look at the composer.json file on Laravel/Framework on github. I can't see how replace will work. Can someone explain to me how this works? And what the variable "self.version" will equal to?
The Composer documentation gives two basic examples. I'll try to explain:
Lists packages that are replaced by this package. This allows you to fork a package, publish it under a different name with its own version numbers, while packages requiring the original package continue to work with your fork because it replaces the original package.
Suppose your software uses original/library and other/package, which itself also requires original/library.
Now you think that original/library needs to integrate a feature, but the maintainers won't let your suggestion happen in their package. You decide to fork that library under the name better/library, and tag a new release.
Back to your software. Of course it should start using better/library, so you require that instead, but that other/package still requires the original/library - code duplication! How can you make that other package to use your better/library instead without also forking it and only changing the composer.json (you are still compatible to that original/library, so it should work)?
You add a replace key to your composer.json:
"replace": {
"original/library":"1.0.2"
}
Now Composer knows that any package from your better/library is equally good as the original/library when it comes to resolving the dependencies of the other/package.
This is also useful for packages that contain sub-packages, for example the main symfony/symfony package contains all the Symfony Components which are also available as individual packages. If you require the main package it will automatically fulfill any requirement of one of the individual components, since it replaces them.
The same rules, a slightly different angle: Requiring components of a framework is a good approach for any other component that needs some feature. But if you require the full framework in your software, and another library, which subsequently also requires a component of that framework, the replace declaration of the framework allows Composer to not have to install that single component twice, because it is already included in the full framework.
Beware: Placeholders in replaced versions are usually bad
In my original answer I suggested:
"replace": {
"original/library":"1.*"
}
This has consequences: Composer will now treat your library version 1.0.0 to be as good as ANY version 1.x of the original library, even if they fix stuff or add features and release version 1.2.34 some day. This also means that if your other/package some day gets an update and requires original/library:^1.1, the replacement in YOUR library is still active and states that it can replace ANY version 1.*, even without you updating anything inside - which it can not, your old code will never implement new features of the original library without you doing some work, but the replacement states exactly this.
So in essence: Avoid wildcard versions in the replacement version! If you use them, you make a statement about the future that you cannot know or predict (unless you can control original/library, but even then be very careful). Always use a specific version of the original/library that you know and can re-implement completely.
When you create your own package, you define in your composer.json what kind of packages does it provide which basically tells Composer that your package has it already installed, so no need to install it again.
If you use replace property, it tells Composer that your package wants to replace the original package with your own fork, so other packages don't need to install it.
For example if a/a package requires b/b and you tell to replace b/b, it won't be downloaded on Composer install/update.
This is explained in more details in here: How does the “replace” property work in Composer?
We are currently running Sitecore CMS 6.5 (120706) with the shared source Item Buckets module installed from here:
https://github.com/jerrong/Sitecore-Item-Buckets/tree/master/sitecorepackages/ItemBuckets%206.5%20NET_40/Final
We wish to upgrade to CMS version 7.0. I'm told that there is currently no upgrade path and to expect one in a few months. However we would prefer not to have to wait on this.
Item buckets is used only for a single section of our site. Everything else is delivered via the standard content tree.
We have tried upgrading to 6.6 first as required by the documented upgrade procedure, despite it mentioning later in the instructions that the shared source item buckets module is unfortunately unsupported for upgrade. Confirmed that this definitely does not work, we receive the error:
Exception Details: System.IO.FileLoadException: Could not load file or assembly 'Lucene.Net, Version=2.3.1.3, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
We also tried disabling Item Buckets by removing the .config files etc. but we had further problems, presumably because of the actual content/data template changes that were made by the Item Buckets update.
We are thinking of trying a clean install of CMS 7.0, and then migrating our custom code base, items in the content tree (including data templates, layouts, renderings, etc) with Sitecore packages to work around the issue.
Can someone validate this approach, or better still suggest a much less painful solution!?
Many Thanks
(this is not official Sitecore advice as that is still being worked on disclaimer,disclaimer!)
Some ideas that might help ..
First we need to work on the data side of things (forget front end code for a second)
You could Un-bucket your items so that they are again plain Sitecore items. You could then remove the item bucket module templates and fields as you mentioned before (by 'unbucketing' you should now have no reliance on the bucketing templates etc.)
You could also look at creating an 'anti-package' using Sitecore Rocks, either way this should give you a site closer to a site before the item buckets module.
You could then get a base/clean install of 6.5 (120706) and then compare it to your working copy 'master' database using a tool like Sitecore Courier.
Sitecore Courier - https://github.com/adoprog/Sitecore-Courier - Allows you to compare 2 versions of Sitecore DB against each other and make an update package of that difference.
This should make you an update package of all the changes that have been made to your 'master' database so that you can, in theory, install this into a fresh copy of Sitecore.
You could see how far this gets you when you install this update package, in theory then you can re-bucket your section that used the old buckets module but using the new built-in buckets.
Front-end code wise, the old item buckets modules way of accessing the search has been completely re-written as that it now uses Linq To Sitecore. Hopefully this will be easier to migrate and the buckets will still work in largely the same way (hopefully better hehe!)
Like Ruud I would be interested to hear about others techniques for doing this.
Any extra complexity could come from thing like :
1) How much customisation of the core database you have done
2) How many new field types and XAML applications you may have written
At this point, there is no good solution for this yet.
If you are actively using the module, there is no way to upgrade right now (not that I know of).
If you are not using the module at all, you can remove everything in Sitecore that has to do with ItemBuckets.
This is a manual job for now... (I've done this with success in a 6.5 environment).
To be sure you remove everything, open the item buckets installation package (the ZIP file) to see what items are installed and manually remove all those items from Sitecore (this will include templates, fields, field types, settings).
You can also use the search in the content editor to search for "itembucket" or "item bucket" and find related items that way.
Another way is to search with SQL directly in the master and core database.
Once you have removed everything in Sitecore and configuration that is related to the buckets, rebuild the link database and run a database cleanup (from control panel) and you should be good to go.
It's a dirty job...
If anyone has a better way, I'd love to hear about it!
the problem you are having there is that the item buckets code was compiled against Lucene.Net 2.9 and Sitecore 7 has v3.0.3.
You could add an assembley binding in in the web.config configuration/runtime section that maps the old version to the new and then fix any issues you get with deprecated methods etc...
You will probably also want to remove the Item Buckets module before the upgrade as suggested as the new bucket templates & items may conflict with the shared source versions. You would at least need to remove the Item buckets config and dll's from the bin folders as these could also conflict.
I don't think there is a simple way of doing it yet or Sitecore would have given out an upgrade path already.
This question already exists, but it is over one year old now and a lot has probably happened if the documentation is a good judge. There is no documented path to migrate from current redmine (2.1) to chiliproject for example.
Chiliproject is a fork of redmine, but I am unable to decide wherever I should migrate or not. There is no clear path as to how I should do the migrations and how much functionality I might loose.
Is there a way to compare the differences between the two projects? Is it worth to spend the time investigating the migration path?
If you have migrated what is your experience?
I searched StackOverflow for the "redmine vs. chiliproject" question because I am having a lot of trouble with installing plugins of any kind on the newest chiliproject version.
Usually, it looks like everything is working fine until you try to update the settings for the plugin (for example, install the Contact Form plugin and try to change something on http://SERVER:3000/settings?tab=contact_form), the debug log shows that the changes were made in the database, but they changes are never loaded back to the plugin page.
I have not been ale to find any documentation on potential changes to the plugin architecture in ChiliProject that would cause this. The plugin page does not list many plugins that are known to work with ChiliProject 3 either.
TL;DR: If you think that you will have any desire to use any existing plugins to extend the functionality of the program you choose, go with Redmine.
I've jumped into a project that uses dotCMS. The problem is that there is only one book about this cms (which is pretty incomplete as far as I concern) and..even their official documentation is incomplete as well.
as far as I now, dotCMS is opensource, but I can't find any .java files.
Anyone knows if I can add/remove core functionalities of dotCMS?
I'm trying to add a new field to categories.
Sure you can. The dotCMS plugin architecture can provide 90% of most functionality you would be looking to add and have the added benifit of not breaking your upgrade path. If you want to modify the source (and the core), you also have access to the community code here:
See:
http://dotcms.com/community/svn-access.dot
for instructions on how to download the source files and see:
http://dotcms.com/docs/1.9/Installation#InstallingFromSVN
on how to get it running from source.
I'm updating a 0.5.1 complete_project to 0.7beta3 + virtualenv + pip + fabric.
I have converted my project into multiple stand-alone applications and I have everything being pulled down by pip from a requirements.txt file.
I am now moving the code over and so far can get the Welcome page and perform a log-in, but then it breaks, due, it appears, to the introduction of Group support and the refactoring of Tribes into Tribes and Topics.
Has anyone successfully made this move? If you did, how did you handle migrating your data? What should I be looking out for? Anyone have a checklist or list of steps? What other exciting challenges do I have to look forward to?
The short answer as far as I'm aware (and I've been following Pinax development for some time now) is that there is no straightforward path to upgrade the project from 0.5.1 to 0.7beta3. I'm not sure how familiar you are with the code, but this is the process I would use based on my limited experience:
Start by using the social_project/ that ships with the latest version of Pinax. Copy into it any changes you made to the settings.py file as well as any custom apps you have.
The templates and media have moved to folders outside of the projects, but if you customized any of them (I'm sure you did) take the custom ones and drop them into the template folders in your project to override those in the default theme folders. You should compare them to those in the theme folders to see what changes may need to be made to keep up with changes in the apps.
The next step would be to do the same thing with urls.py copying any customizations over the one provided by the project.
Try getting it running at this point with a fresh DB. Hopefully any errors will point you in the right direction to stuff that you might have missed or not known about.
Once you gotten it running most of the DB tables should be the same (I believe) except as you mentioned the Tribes stuff. Migrating the data, though, is still beyond what I've had to deal with.
Disclaimer: I've been following development but never had to perform an upgrade quite this big. Good luck and (obviously) back up your work and data before trying to port it all over.
See the documentation and code ( http://github.com/pinax/pinax/tree/master ) for more details. The code is a convenient (though tedious) way to watch the evolution between 0.5.1 and 0.7beta3, for what that's worth.