{"action":"closed","issue":{"url":"https://api.github.com/repos/nanoc/nanoc/issues/541","labels_url":"https://api.github.com/repos/nanoc/nanoc/issues/541/labels{/name}","comments_url":"https://api.github.com/repos/nanoc/nanoc/issues/541/comments","events_url":"https://api.github.com/repos/nanoc/nanoc/issues/541/events","html_url":"https://github.com/nanoc/nanoc/issues/541","id":67805609,"number":541,"title":"Feature request: Finer-grained dependency tracking","user":{"login":"jugglinmike","id":677252,"avatar_url":"https://avatars.githubusercontent.com/u/677252?v=3","gravatar_id":"","url":"https://api.github.com/users/jugglinmike","html_url":"https://github.com/jugglinmike","followers_url":"https://api.github.com/users/jugglinmike/followers","following_url":"https://api.github.com/users/jugglinmike/following{/other_user}","gists_url":"https://api.github.com/users/jugglinmike/gists{/gist_id}","starred_url":"https://api.github.com/users/jugglinmike/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jugglinmike/subscriptions","organizations_url":"https://api.github.com/users/jugglinmike/orgs","repos_url":"https://api.github.com/users/jugglinmike/repos","events_url":"https://api.github.com/users/jugglinmike/events{/privacy}","received_events_url":"https://api.github.com/users/jugglinmike/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-04-11T16:40:23Z","updated_at":"2015-04-18T21:12:04Z","closed_at":"2015-04-18T21:12:04Z","body":"Would it be possible for nanoc's dependency tracker to make a distinction between item contents and item attributes? In other words: can nanoc recognize when a representation only depends on an item's attributes so that even when item content changes, that representation is not re-compiled?\r\n\r\n### Example use case:\r\n\r\nI'm working on a site that offers content in a few languages. For pages with multiple translations, I would like to render links to the alternate versions. One way I've prototyped this is through an item attribute named `canonical`.\r\n\r\n- `content/hello.md`\r\n\r\n        ---\r\n        ---\r\n        Hello.\r\n- `content/pt-br/ola.md`\r\n\r\n        ---\r\n        canonical: /hello/\r\n        ---\r\n        Ola.\r\n- `content/es-mx/hola.md`\r\n\r\n        ---\r\n        canonical: /hello/\r\n        ---\r\n        Hola.\r\n\r\nWith this setup, I can create a hash of identifiers in a `preprocess` block and store it as a `:locales` attribute on the \"canonical\" item. I can then access this from a layout generally via code like:\r\n\r\n```erb\r\n<%\r\ncanonical = @item[:canonical] ? @items[@item[:canonical]] : @item\r\ncanonical[:locales].each { |lang, id|\r\n  render(\"locale_link.md\", :lang => lang, :id => id)\r\n}\r\n%>\r\n```\r\n\r\nThe problem here is that nanoc's dependency tracker (correctly) detects that I am referencing the \"canonical\" item, and it registers this as a dependency. Now, whenever the \"canonical\" version's *content* changes, the localized representations are needlessly re-compiled.\r\n\r\nThis is not so bad, except that I would also like to use this mechanism to generate static links in a generic \"header\" layout shared between most pages on my site:\r\n\r\n```erb\r\n<%\r\nlink_text = translate(\"contact\")  # defined elsewhere (not directly relevant)\r\ncurrent_locale = @item[:locale]   # (inferred from item identifier)\r\ncontact_href = @items['/contact/'][:locales][current_locale]\r\n%>\r\n<nav id=\"site-main-menu\">\r\n  <a href=\"<%= contact_href %>\"><%= link_text %></a>\r\n  <!-- (additional navigation links here) -->\r\n</nav>\r\n```\r\n\r\nIf I re-use this across the site, then any change to the *content* of the `/contact.md` item will trigger recompilation of every page. This is the behavior I would like to avoid.\r\n\r\n---\r\n\r\nMy use case is obviously far more specific than the feature request suggests. I've tried to propose a solution that makes sense for nanoc generally outside of this context. That said, I'm very open to suggestion for other ways to avoid this problem. If I can do this with nanoc's current features (maybe there's a better way to structure my content?), then that would obviously be ideal. It might also be the case that there are alternative ways to extend nanoc that would help me here (for instance, defining a public API for the dependency tracker so I could express this relationship explicitly).\r\n\r\nThanks for the great tool!"}}