[hoov]

"Just use Ruby" isn't always the best option; if you have a large base of Python code, it's probably preferable to use Python directly rather than using the subprocess module.

Also, a port would be fairly straightforward. Some combo of the struct/ctypes modules (depending on how complicated the data structures are) would make a transliteration pretty simple.

[sjtgraham]

A "large base of Python code" would not be my main reason for eschewing other languages:

- Unfortunately psd.py doesn't seem to exist. Tell me, what is less effort: Implementing that, or building a small app/service that performs the functionality you need using existing tools?

- Also I'd consider the suitability of a given technology before this too, e.g. on my current project there is a lot of Ruby code, but it's a major bottleneck in one of our services performing a particular task. We rewrote that service in Clojure and it performs orders of magnitude faster and uses orders of magnitude less memory.

[hoov]

> Tell me, what is less effort: Implementing that, or building a small app/service that performs the functionality you need using existing tools?

I think it depends on your use case. In certain cases, you want to do work inline. In other cases, you want to do PS manipulation in the background. I could imagine projects that go in either direction. If I had a large Python desktop application, I'd port the code. If I had a Django application that wanted to do background processing of PS documents, I'd put the work on a queue and have Ruby take care of the messy bits.

> Also I'd consider the suitability of a given technology before this too, e.g. on my current project there is a lot of Ruby code, but it's a major bottleneck in one of our services performing a particular task. We rewrote that service in Clojure and it performs orders of magnitude faster and uses orders of magnitude less memory.

I take a different approach. If I find a bottleneck in Python code, I use ctypes or write a C extension. I'd do the same thing in Ruby. I'm hesitant to deploy multiple runtimes, since I worry about security updates, etc. If I were on JRuby, Clojure would be a natural fit -- I'd only be deploying one JVM.

[kmike84]

> Unfortunately psd.py doesn't seem to exist.

This is just plain wrong. There are many Python readers for PSD format:

* https://github.com/kmike/psd-tools

* https://github.com/jerem/psdparse

* https://code.google.com/p/pypsd/

* PIL and Pillow can read PSD files.

I'm biased because I wrote psd-tools, but I think psd-tools API is quite simple, and it has some features that PSD.rb doesn't have, e.g. it supports more PSD compression formats (actually, all of them) and can export individual layers and layer groups as images. It also has more tests than PSD.rb and more PSD files in testing suite.

[sjtgraham]

Nice. Obviously I didn't look too hard hence "doesn't seem to exist". My main point was against reimplementing something already extant just because you have a swathe of code in a given language.

[kmike84]

Your point applies more to PSD.rb then - there was a lot of PSD readers in Python, C, C++ and C# for ages :)

But it seems that reimplementing worked very well for them: API, language and a good timing really matters.