Otevírání služby Připravto pro komunitu a API přístup (diskuse)

[pavel]

Ahoj, libi se mi to.

Znas X3D, resp X3DOM.js ? Umoznuje to generovat 3D scenu v XML podobne jako vytvaris 2D scenu v SVG/XML.

Tip

[Normotron]

No ve skutečnosti služba generuje celá data ve 3D a následně je pouze vykreslujeme do 2D. Máme výstupy do DXF 2D a 3D, OBJ a BLEND. S tím souvisí i vizualizace. Jinak v současné době se spíše snažíme používat jako formát JSON.

Ale určitě se na to mrknu, neznám to. V minulosti jsme používali ThreeJS. Nyní od toho upouštíme, jelikož to pro naše potřeby zatím neumíme dobře ohnout.

[pavel]

X3D proste pridava jednu dimenzi nad SVG, nic vic, nic min. X3D Hello wolrd

[Marián Kyral]

Ty průhledné obrázky vypadají na tmavém pozadí zajímavě

[Normotron]

Očekával bych že spíše nejsou vůbec vidět. Je škoda, že tam nejde vložit svg, tam se dá změnit dobře pozadí.

[Odin1918]

Pip install ocapi... Neprestavam zasnout, jak divne nazvy maji opensourcove projekty.

[Normotron]

To je jednoduché :) lze si to představit jako oc-api > OptimCabinet-Application Programming Interface. Není v tom žádný složitý systém. Původní program na, kterém je Připravto postavené se jmenuje OptimCabinet :D

Je mi jasné, že by jména mohla být lepší, ale tohle je api, takže jsme to moc neřešili. Máte nějaké vhodné jméno?:)

[Odin1918]

Ona to nebyla kritika. Uprimne ja bych sam lepsi jmeno jiste nevymyslel a muj vytvor by zase prisel divny nekomu jinemu.

[Josef Kufner]

Já bych to nechal delší a nezkracoval tolik. Aspoň by se to lépe hledalo.

[frm]

hned to prvni nejak nefunguje ...

[jan@rixo ~]$ pip install ocapi
-bash: pip: command not found
[jan@rixo ~]$

Pouzivam:

[jan@rixo ~]$ uname -a
Linux rixo 2.6.18-398.el5PAE #1 SMP Tue Sep 16 21:31:44 EDT 2014 i686 i686 i386 GNU/Linux
[jan@rixo ~]$ cat /etc/issue
CentOS release 5.11 (Final)
Kernel \r on an \m

[pavel]

Co zacit treba yumem?

[00000]

Pokud to propojíte s nějakým (velkým v budoucnu) stolařem (výrobcem nábytku), bude to bomba.

Navrhnout a za týden: "Nazdar paní, jdeme Vám montovat tu skříňku, co jste si navrhla...".

Můžete přidat rekonstrukci koupelen.

[Normotron]

Pokud máte na vhodného stolaře kontakt, určitě se sním můžeme spojit. Ono sice tam jde navrhovat takto také, ale spíše je to vhodnější pro profesionála, jelikož si to již dovede hned představit jak to pak bude vhodně vyrábět a může si to uzpůsobit. ;)

Rekonstrukce koupelen - Já tomuto tématu moc nerozumím, takže to je spíše otázka pro někoho kdo se v tom vyzná, jestli by to se současnou platformou šlo. Očekáváme, že za nějakou chvíli bude ve službě možné dělat např. schody a částečně tesařské konstrukce.

[Normotron]

pip je instalační program pro Python. Více viz https://pypi.python.org/pypi/pip

Tzn je to něco jako yum, až na to, že je to určené pro Python. Nejdříve přes yum nainstalujte pip a následně můžete nainstalovat ocapi.

Bohužel pip je v základu dostupný v Pythonu 3.4 a 2.7.9 na ostatních se musí instalovat. Obvykle ale bývá nainstalován. Používá ho mnoho programů pro Python.

[Petr Tomášek]

Kombinovat různé balíčkovací systémy na jednom systému je prasárna. Ale jasně, perl takovou cípovinu má, php taky, tak to musí mít i pýčon...

[Václav "Darm" Novák]

Používám víc verzí ruby a pod nima několik sad gemů různých verzí. Jak by se taková změna běhových prostředí dala optimálně řešit balíčkovacím systémem? U debianu třeba bootstrapem do různých adresářů a chrootem, pravda. Jenže to je oproti rvm dost obludné řešení.

[pavlix]

Jak by se taková změna běhových prostředí dala optimálně řešit balíčkovacím systémem?

Asi úplně stejně jako se řeší tím jiným balíčkovacím systémem, ne? Na Gentoo třeba jenom v ebuildu uvedu, pro které verze Pythonu je balíček určený.

[Normotron]

No jde ještě o to, že pip je multiplatformní funguje jak ve Windows, tak na Mac OS X, takže je vhodné dělat balíčky, tak aby byly dobře dostupné. No a pip se o to docela dobře postará.

Spolu s virtual env je to hodně silný nástroj.

[pavlix]

To už je ovšem úplně jiná story a nevidím v tom osobní přínos, narozdíl od souběžného provozu několika verzí platformy pro daný jazyk.

[Václav "Darm" Novák]

Možná v gentoo, nedovedu si to představit příliš reálně v Archu nebo Debianu, pokud si nechci balit sám.

Podle mě se jedná o výborný způsob distribuce knihoven pro interpretované jazyky. U nich hlídání závislostí na systémových komponentách nemá důvod, důležitá je kontrola závislosti na verzi ruby a mezi jednotlivými knihovnami.

Konkrétně v ruby: Mohu mít několik verzí ruby současně pomocí rvm, zároveň několik různých sad knihoven v jednotlivých verzích. Přepínání běhového prostředí není problém. Moje aplikace v Rails má gemfile se specifikovanou sadou gemů které používá a nasazení kdekoliv se tím neskutečně zjednodušuje. Po synchronizaci s repozitářem nebo zkopírování přes ftp spustím bundle update a vše potřebné se do nového prostředí stáhne. A je mi celkem jedno jestli tam běží gentoo, debian, centos, SLES, nebo Windows, jestli jde o openshift nebo heroku. Zároveň můžu zadat update jen minor verzí knihoven a udržovat celé prostředí aktuální bez možnosti rozbití kompatibility.

Navíc si celkem nedovedu představit jak někdo balí všechny ruby knihovny/programy z rubygems pro všechny distribuce. Třeba v Archu jich je celkem hodně, mnoho jich je v AUR. Zdaleka ne všechny a problém to prostě neřeší. Nebo ano? Jestli lze tohle všechno dělat s balíčkovacími systémy distribucí bez přidělávání si práce tvorbou vlastních balíčků (a ideálně bez závislosti na konkrétní platformě), rád se poučím :)

[pavlix]

Možná v gentoo, nedovedu si to představit příliš reálně v Archu nebo Debianu, pokud si nechci balit sám.

Tohle je spíše věc pythoních distutils, které takhle hezky fungují (až na nepříjemnosti typu sbin). Vytvořit triviálně balíčky pro několik verzí Pythonu pak umí každá distribuce, kde na to někdo tu automatizaci napsal. V zásadě je to jen pár shellovských funkcí. Gentoo má tu výhodu, že si s tím někdo dal tu práci. Nikde jinde jsem to zatím nezkoušel, ale nevyužívá se tam nic, co by bylo pro Gentoo nějak specifické.

V zásadě by nebyl problém ten kód mezi distribucemi sdílet třeba v rámci pythoních distutils. Je potřeba si uvědomit, že je to vcelku triviální automatizace, jen se musí najít někdo, kdo má motivaci ji připravit a především někdo, kdo má motivaci ji nadále udržovat.

Navíc si celkem nedovedu představit jak někdo balí všechny ruby knihovny/programy z rubygems pro všechny distribuce.

V dobře udělané distribuci spočívá příprava balíků v sepsání několika řádků metadat. Jestliže ta metadata už někde na serveru pohromadě jsou, v zásadě by nebyl problém, kdyby tím někým, kdo balí všechny knihovny/programy byl vcelku jednoduchý skript. Výsledek by byl stejně nekvalitní, jako když ten server používáš přímo, ale v dalším kroku by nad tím bylo možné udělat nějakou stabilizaci verzí jako přidanou hodnotu.

Zdaleka ne všechny a problém to prostě neřeší. Nebo ano?

Jistěže ano, podstata je v tom, že zabalit takovou knihovnu by nemělo být složitější než ji nainstalovat. V extrémním případě by bylo možné řešit to pluginem do systémového balíčkovače a balíčkování by odpadlo úplně a řešila by se následná úprava metadat. Konec konců by se stejný princip dal aplikovat i na céčkovské projekty, pokud by používali nějakou malou množinu dobře detekovatelných a ovladatelných build systémů, alespoň tedy pro projekty, které fungují dobře ve výchozí konfiguraci.

[Václav "Darm" Novák]

OK… Tohle by řešením bylo. Ještě nějak umožnit instalovat balíčky pod lokálním uživatelem do jeho vlastního prostředí a prosadit standard pro všechny distribuce. A nebo použít už existující standardizované řešení, které funguje všude :) Já nevím, stále mi připadá stávající řešení lepší.

[pavlix]

Ještě nějak umožnit instalovat balíčky pod lokálním uživatelem do jeho vlastního prostředí

Na úrovni lokálního uživatele si zatím vystačím s těmi nástroji specifickými třeba pro Python. Lokálních balíků mívám málo a když se to nějak pokazí, tak mě nebolí si najít ten adresář, promazat ho a naházet tam jenom to, co potřebuju. Teoreticky by to šlo i na úrovni systému, ale tam je prostě problém ten, že cokoli tam nainstaluješ, tak se ti může nějak vymstít.

a prosadit standard pro všechny distribuce.

To zní hrozně vznešeně a složitě, přito by stačilo standardizovat jenom pár drobností a klidně by se to mohlo týkat jenom určité třídy software. Třeba v případě Pythonu už je do značné míry standardizováno, i když je samozřejmě, co zlepšovat.

Já nevím, stále mi připadá stávající řešení lepší.

Já osobně nevidím vůbec prostor pro srovnání, nebavíme se o konkurenčních technologiích, ale o jednotlivých dílech skládačky. Ani to Gentoo nevnímám jako distribuci, na kterou by měli všichni přejít, ale spíš jako skupinu lidí, která vyrobila některé dílky skládačky o kterých si jiní zatím můžou nechat jenom zdát.

[Václav "Darm" Novák]

Možná ty… Pokud jde například o mnou zmíněný openshift, heroku nebo jiné podobné cloudové služby, rubygems, pip a podobné jsou asi nejschůdnější řešení.

[Normotron]

Ano také to tak vidím, jde o to, že pip je docela dobře přístuný, Neříkám, že je dokonalý, má hodně svých chyb, třeba vyžaduje určitou strukturu projektu, dále nutnost zapisovat většinu souborů do setup a tak podobně a pro větší projekty, již nemusí stačit. Avšak pro menší je rychlý a efektivní.

[pavlix]

Asi si nerozumíme.

[Dvojité Wéčko]

Kdybys neměl na své pracovní stanici roota, byl bys za tyto prasárny velmi vděčný.

[Normotron]

pokud nemůžete použít PIP, ale máte Python a setup tools, tak možná bude pro Vás jednodušší zkusit variantu přímo přes.

wget https://bitbucket.org/pripravto/ocapi/get/default.tar.gz
tar -xvf default.tar.gz
cd pripravto....

nainstalovat přes setup

python setup.py install

Nebo jen rozbalit a na importovat přes Python.

$ python

>>> import ocapi.api as api

[Petr Tomášek]

A nebylo by jednodušší zabalit to do do DEB/RPM/... a slušně to nainstalovat?

[Bystroushaak]

Ne, nebylo, bylo by to podstatně složitější, nehledě na závislosti, které skoro určitě v DEB/RPM nebudou a spravovat je a dostávat do distribuce je práce pro masochistu.

PIP je standard pro distribuci python balíčků a jako takový v DEB/RPM je, tak nevidím problém v jeho instalaci. Někdy to jde i přes easy_install: sudo easy_install pip.

[pavel]

proc ne rovnou easy_install ocapi ?

[Bystroushaak]

Měli by jste si přidat i nějaké to description do setup.py.

$ pip search ocapi
ocapi                     - UNKNOWN

[Normotron]

Jo, děkuji za připomenutí, omylem jsem ho před tím vymazal.

[Bystroushaak]

Pripravto api connect to OptimCabinet service mi přijde takový dost zmatený a asi bych vůbec nepochopil, co že to má být.