Re: gem, pip et al vs. pkg

[Torsten Zuehlsdorff]

On 08.06.2016 02:53, Kurt Jaeger wrote:

Hi!


The ports tree has thousands of entries, which are simply thin wrappers
around Ruby's gem or Perl's and/or Python's pip.


Thanks again for asking the right questions. Please add go to that
list 8-}


Why do we need them? Obviously, it is primarily
for other ports to be able to depend on them. But why can't we satisfy
this need without creating a port for each such little package?


Because right now the mechanism we use is the only one we have.


If a port declares:

RUN_DEPENDS= /foo/:gem//bar/[:/version/]

why can't the /bar/-gem (with the latest or specified version) be
automatically installed -- and/or registered as a dependency -- without
there being a dedicated port for it?


We would need to mirror the language-specific dependency tracking
in the ports system. While doable, it's definitly non-trivial.


Also it is not always language specific. Some rubygems for example 
requires other non-ruby software to be installed. This is handled by the 
ports very good - but if there is no such requirement a port is 
overhead. Also gems allow/need sometime specific versions - which is 
hard to track and keep right in the ports tree.


Greetings,
Torsten

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: gem, pip et al vs. pkg

[Kurt Jaeger]

Hi!

> The ports tree has thousands of entries, which are simply thin wrappers 
> around Ruby's gem or Perl's and/or Python's pip.

Thanks again for asking the right questions. Please add go to that
list 8-}

> Why do we need them? Obviously, it is primarily 
> for other ports to be able to depend on them. But why can't we satisfy 
> this need without creating a port for each such little package?

Because right now the mechanism we use is the only one we have.

> If a port declares:
> 
> RUN_DEPENDS= /foo/:gem//bar/[:/version/]
> 
> why can't the /bar/-gem (with the latest or specified version) be 
> automatically installed -- and/or registered as a dependency -- without 
> there being a dedicated port for it?

We would need to mirror the language-specific dependency tracking
in the ports system. While doable, it's definitly non-trivial.

> In the other direction, if someone were to install a Ruby gem using the 
> gem-utility (or pip-perl, or pip-python, or even rpm), why aren't the 
> installed files registered in the pkg's database? We have the sources 
> for all of these utilities -- we can modify them to register the package 
> and its files with the pkg.
> 
> The changes may even be welcomed upstream, if they are abstract enough 
> to allow registration with the Operating System's package-manager on 
> /all/ OSes, which would bother implementing a custom backend...

Sounds valid, now someone has to implement this -- and send
it upstream for each language.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

gem, pip et al vs. pkg

[Mikhail T.]

The ports tree has thousands of entries, which are simply thin wrappers 
around Ruby's gem or Perl's and/or Python's pip.


Most of these ports conWhy do we need them? Obviously, it is primarily 
for other ports to be able to depend on them. But why can't we satisfy 
this need without creating a port for each such little package?


If a port declares:

   RUN_DEPENDS= /foo/:gem//bar/[:/version/]

why can't the /bar/-gem (with the latest or specified version) be 
automatically installed -- and/or registered as a dependency -- without 
there being a dedicated port for it?


The biggest problem here is that neither Python's 
 
nor Ruby's  packages are normally 
/signed/ (not sure about Perl's), so simply downloading them is 
dangerous (not that this stops all people from using them anyway). But 
this can be side-stepped by us maintaining a checksum file of our own -- 
it would still be easier and more concise to maintain such a table with 
one row per package, instead of an entire port-directory with multiple 
files in it.


In the other direction, if someone were to install a Ruby gem using the 
gem-utility (or pip-perl, or pip-python, or even rpm), why aren't the 
installed files registered in the pkg's database? We have the sources 
for all of these utilities -- we can modify them to register the package 
and its files with the pkg.


The changes may even be welcomed upstream, if they are abstract enough 
to allow registration with the Operating System's package-manager on 
/all/ OSes, which would bother implementing a custom backend...


   -mi

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"