Campos de una herramienta

[pedroburon]

Definiré un paquete o aplicación o componente o biblioteca como "HERRAMIENTA" para seguir con la metáfora del toolbox.

Qué campos debe tener una "herramienta" para cumplir con lo mínimo necesario.

[elmarcoh]

Creo que depende de donde se vayan a obtener los datos pero creo que:

• Nombre
• Categoria(s)
• Reseña
• Mantenedor (o autor)
• Licencia
  • Sería interesante simplificar esto a "Se puede usar en proyectos comerciales" o no
• Nombre en pypi
• URL de web del proyecto
• URL github/bitbucket/otro repo
• Framework (en caso que la herramienta sea para uno)

con eso creo que ya es utilizable como indice de paquetes

[pedroburon]

• Nombre
• Categoria(s)
• Reseña (¿Esto sería una reseña de los administradores?)
• Mantenedor (o autor)
• Licencia
• Nombre en pypi (¿qué pasa si no está en pypi?, ¿no debería estar dentro de toolbox?)
• URL de web del proyecto (¿Lo mismo, qué pasa si no tiene url?)
• URL github/bitbucket/otro repo ( IDEM )
• Framework (en caso que la herramienta sea para uno) *(Creo que debería tener las dependencias más que un framework en particular) *

Me parece que una decisión que se podría tomar es que no vayan los paquetes que no están en pypi, dado que no se pueden instalar fácilmente (?).

Con respecto a la url del proyecto, si no existe podría ser la de pypi, sólo si aceptamos que todos estén en pypi.

[glarrain]

Además la URL de la documentación, si es pure Python, requisitos de versión de Python

[glarrain]

Y tags para complementar la clasificación vertical

[pedroburon]

Los tags podrían ser los mismos de las categorías (classifiers) de pypi.

http://pypi.python.org/pypi?%3Aaction=list_classifiers

[glarrain]

Para algunos tópicos esos son un poco limitados. ¿Quizás partir de aquellos y agregar otros más? ¿Los tags que use Ruby toolbox?

[pedroburon]

Podríamos partir entonces con los classifiers de pypi, para hacer una
prueba de concepto nos servirían los otros tags?

-.-. .... .- ---
Pedro Burón Valencia
CTO at Witoi.com

2013/1/2 German Larrain [email protected]

Para algunos tópicos esos son un poco limitados. ¿Quizás partir de
aquellos y agregar otros más? ¿Los tags que use Ruby toolbox?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-11830204.

[glarrain]

Ok

[elmarcoh]

Como tags los classifiers me parecen excelentes.

Respecto a los comentarios de pedro:
La reseña aún no sé que origen puede tener; pypi las tiene, pero muchas las encuentro bastante malas, deberiamos poder manejar una reseña paralela.
Los "que pasa si no tiene X" simplemente no debería mostrarse, habria que definir que datos son obligatorios de todas formas.
Lo de los frameworks y dependencias; me parecen casos un tanto distintos, ya que un framework es una dependencia excluyente hacia otros frameworks, no sería muy util obtener resultados que dependan de django si mi proyecto es flask, pero es válido tener resultados que dependan de, por ejemplo, 2 modulos distintos de serialización.
De todas maneras podriamos tener las dependencias; toda informacion que se pueda obtener podria ser incluida, el tema es si finalmente se usará para alguna funcionalidad o solo será desplegada.

[glarrain]

Sobre frameworks y dependencias, creo que se puede entender de la siguiente forma:

• frameworks: es aquello para lo que está creado el paquete X, para integrarse con X.
• dependencia: es aquello necesario para que X haga lo que dice que hace.

Naturalmente los frameworks son también dependencias en la mayoría de los casos.

Con tags "libres" se podría cubrir todo esto pero también se puede desordenar fácilmente y complicar la búsqueda.