Alex Rades a écrit :
Hi,
Which is very very handy, it handles all my use case in a compact and nice way. The minitage.recipe.scripts is nice but is not widely used,
But supported by a company which will do not switch for another recipes. We deploy on various systems, that's why we created minitage both as sysadmins and developers efforts.
so I'm a bit worried about its future and possible breakages.
We have a tracker, mails & irc and we don't like to have spending bugs for a long time ;) You know
- when you work on a large project you have to think hard about your dependencies. It's like getting married.
If minitage is dead, all our current deployments (lot of projects) there will be in bad shape. Just a word to say that you ll have years to see it dead.
So the question is: Are there alternative solutions? Am I the only one with such needs? This is not only the way to do, and i told you the alternatives like doing with mr.developer. That depend on your feelings and habits and use cases.
I like very much both my recipes and mr.developer, When i need to apply a small change, mostly for upstream approval, i go for minitage.recipe.scripts. Or for a single patch without hacking, (ZODDB + RelStorage, for example), i go also for minitage.recipe.scripts. But for more deeper hacking, i'd go for mr.developer.* After that, there are much more things in minitage.recipe.* that zc.equivalent, that i can't do without forking them and that's that i ve done that, some years ago. Now their code is too much different, and it was not a primary goal too, to merge back. Specially for minitage integration, even if you are not tied with minitage by using only the recipes, i don't think the code integrating it belongs to any zc.recipe.*.
Thank you _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF