{"action":"created","issue":{"url":"https://api.github.com/repos/CompEvol/beast2/issues/558","repository_url":"https://api.github.com/repos/CompEvol/beast2","labels_url":"https://api.github.com/repos/CompEvol/beast2/issues/558/labels{/name}","comments_url":"https://api.github.com/repos/CompEvol/beast2/issues/558/comments","events_url":"https://api.github.com/repos/CompEvol/beast2/issues/558/events","html_url":"https://github.com/CompEvol/beast2/issues/558","id":156477040,"number":558,"title":"XML should store a list of needed packages.","user":{"login":"SimonGreenhill","id":220169,"avatar_url":"https://avatars.githubusercontent.com/u/220169?v=3","gravatar_id":"","url":"https://api.github.com/users/SimonGreenhill","html_url":"https://github.com/SimonGreenhill","followers_url":"https://api.github.com/users/SimonGreenhill/followers","following_url":"https://api.github.com/users/SimonGreenhill/following{/other_user}","gists_url":"https://api.github.com/users/SimonGreenhill/gists{/gist_id}","starred_url":"https://api.github.com/users/SimonGreenhill/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/SimonGreenhill/subscriptions","organizations_url":"https://api.github.com/users/SimonGreenhill/orgs","repos_url":"https://api.github.com/users/SimonGreenhill/repos","events_url":"https://api.github.com/users/SimonGreenhill/events{/privacy}","received_events_url":"https://api.github.com/users/SimonGreenhill/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2016-05-24T10:49:28Z","updated_at":"2016-05-26T19:18:12Z","closed_at":null,"body":"As the BEAST2 package system proliferates, there are more and more packages that add functionality. \r\n\r\nOne side effect of this is that it becomes harder to distribute XML files as it's not clear what packages they rely on. This goes against the philosophy of having the XML file contain everything needed to replicate the analysis. And it can lead to puzzling errors e.g. one I came across recently was:\r\n\r\n```\r\nnullClass could not be found. Did you mean beast.evolution.tree.RandomTree?\r\n```\r\n\r\nThis was because I didn't have (I think) the BeastLabs package installed. \r\n\r\nIt would be nice to add the information that an analysis requires package X (version Y) into the XML file somehow.\r\n\r\nOne alternative would be to generate a more understandable error message e.g. \"...which can be found in Package X\", but I'm not sure how this might work as BEAST doesn't know about all the add-ons that are out there until they're installed.\r\n\r\nHowever, BEAUTi knows what packages its using to generate the XML, so another alternative would be to add a list of required packages into the XML when generated as an explicit \"requires\" style statement. This could also include version information e.g. \r\n\r\n```\r\n<requires package=\"BeastLabs\" source=\"http://....\" version=\"...\" />\r\n```\r\n\r\nOr perhaps by injecting it into the <beast> namespace tag:\r\n\r\n```\r\n<beast beautitemplate='..' beautistatus='' namespace=\"beast.core:2.4.1:beastLabs:1.5.3...\">\r\n```\r\n\r\n... and BEAST could check this when running and fail if it can't find the required package (and same/newer version).\r\n"},"comment":{"url":"https://api.github.com/repos/CompEvol/beast2/issues/comments/221967650","html_url":"https://github.com/CompEvol/beast2/issues/558#issuecomment-221967650","issue_url":"https://api.github.com/repos/CompEvol/beast2/issues/558","id":221967650,"user":{"login":"rbouckaert","id":3612959,"avatar_url":"https://avatars.githubusercontent.com/u/3612959?v=3","gravatar_id":"","url":"https://api.github.com/users/rbouckaert","html_url":"https://github.com/rbouckaert","followers_url":"https://api.github.com/users/rbouckaert/followers","following_url":"https://api.github.com/users/rbouckaert/following{/other_user}","gists_url":"https://api.github.com/users/rbouckaert/gists{/gist_id}","starred_url":"https://api.github.com/users/rbouckaert/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rbouckaert/subscriptions","organizations_url":"https://api.github.com/users/rbouckaert/orgs","repos_url":"https://api.github.com/users/rbouckaert/repos","events_url":"https://api.github.com/users/rbouckaert/events{/privacy}","received_events_url":"https://api.github.com/users/rbouckaert/received_events","type":"User","site_admin":false},"created_at":"2016-05-26T19:18:12Z","updated_at":"2016-05-26T19:18:12Z","body":"Sure, the problem remaining is to find out which packages are required by an analysis, which requires tracking the classes used in an analyses as well as tracking which packages provide these classes. The former requires a simple traversal of the graph, which is not hard. \r\n\r\nThe latter requires a bit more thought: I suppose it is sufficient to just check all classes in the package/lib/package.addon.jar files, assuming that each package has its classes there. Where things get hairy is when more than one package include a library (say XYZ.jar) and there is some input of a type from such library. Then it requires XYZ.jar from package A or from package B, but it is not easy to determine which one to put in the `require` attribute (rather than element, we do not want any extra special XML elements that need explaining and special handling by the XMLParser). If we only consider classes from the package library, we have to rely on them being identifiable. The naming convention most (but not all, e.g. STACEY) packages are using is to have the library in package/lib/package.addon.jar.\r\n\r\nAs Tim brought up, another consideration is that package B can be dependent on package A, but only classes in package B end up in the analysis. In that case, package A and B are required, but only package B will be in the `require` attribute. If packages A and B are missing then installing package B will automatically get package A installed (or if not, will result in error messages at the start explaining package A is missing) so I don't think this is a big issue."}}
{"actor":{"display_login":"rbouckaert"}}