| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
There isn't yet an official spec for distribution names in python,
however there is a draft at http://legacy.python.org/dev/peps/pep-0426/#name
In particular,
"All comparisons of distribution names MUST be case insensitive,
and MUST consider hyphens and underscores to be equivalent."
pkg_resource.parse_requirements will replace any underscores in the
package name as hyphens, so when we search pypi we need to look for
the package name with underscores as well as with hyphens.
|
| |
|
|
|
|
| |
Morph doesn't need a chunk morph to build/install setuptools packages,
but the import tool needs to grow the ability to have 'to_chunk' as an
optional stage before we can remove this part of the python extension.
|
| |
|
|
|
| |
python.find_deps does some pretty basic validation of the requirement specs,
this commit adds the tests for this validation.
|
| |
|
|
|
| |
This takes source_dir, name, version and returns the dependencies for the
package as json on stdout.
|
| | |
|
| |
|
|
| |
This takes source, name, version and produces a lorry
|
| | |
|
| |
|
|
|
|
|
|
| |
The multi_json Gem wasn't being detected as signed, because the
'signing_key' field is an expression that can evaluate to 'nil' in some
cases. In this Gem the 'cert_chain' field was still a standard string.
Hopefully checking for the presence of either will catch all cases
(and false positives should be harmless anyway).
|
| |
|
|
|
| |
This was motivated by <https://github.com/mislav/will_paginate>, which
links to <https://github.com/mislav/will_paginate/wiki> as its homepage.
|
| |
|
|
|
|
| |
The rubygems.to_chunk tool was assuming the .gemspec file always lived
at the top of the chunk repo, but this isn't the case for
<https://github.com/rails/rails>. Now it is smarter.
|
| |
|
|
|
|
|
| |
This is used to ignore Gems which either come built into Ruby (like
Rake) or are supplied with the 'ruby' stratum. As noted in the comment
in the .yaml file it is not an ideal solution, but it should work well
enough for the time being.
|
| |
|
|
| |
This is cool because now you can import Ruby on Rails.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By calling Bundler::Dsl.gemspec without specifying :path, this tool
was causing the Bundler::Source::Path instance for the target .gemspec
to be for path '.', which is relative path that is only valid inside
one Dir.chdir block. It seems that all the Bundler resolution code runs
inside that block and so there should be no problem, but unless we
specify an absolute path for the gemspec then errors like this sometimes
appear:
/usr/lib/ruby/gems/2.0.0/gems/bundler-1.7.6/lib/bundler/resolver.rb:357:in
`resolve': Could not find gem 'ffi-yajl (>= 0) ruby' in source at ..
(Bundler::GemNotFound)
Source does not contain any versions of 'ffi-yajl (>= 0) ruby'
This normally happens when an Omnibus import chains to rubygems.to_chunk
for a RubyGem component.
The path is clearly valid at the time Bundler::Dsl.gemspec is called
(otherwise it'd raise a Bundler::InvalidOption exception at the time)
but not valid later (hence the error). Note that the second '.' in that
error message is a full stop and not part of the path!
|
| | |
|
|
|
It's slightly annoying during development, but the exts/ must be inside
the package or it would be installed somewhere silly like
/usr/lib/python2.7/site-packages/exts.
|
